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Com vocês aprendi o que realmente importa. 


Prefácio 


N ão, este livro não contém um roteiro para a implantação da ITILO, até 
porque, como todos sabem, ITILº não se implanta! Também não é um 
livro de revisão de conceitos como tantos outros, pois todos os conceitos de 
que precisamos já estão no material oficial da ITTL® e já são vistos durante 
os treinamentos de ITIL Foundationsº. Este livro tem algo muito diferente: 
tem dezenas de orientações sobre o que fazer e o que não fazer para ter su- 
cesso na implantação da gestão de serviços de TI (GSTI) usando as melhores 
práticas da TTILº, qualquer que seja sua versão. 

Você verá, já no Capítulo 1, que o próprio nome do livro é, intencional- 
mente, um convite à reflexão de que o que realmente importa não é a ITILº, 
mas sim a GSTI e que este será o nosso principal assunto. 

Nosso objetivo é bastante claro: estabelecer os próximos passos para 
aqueles que se iniciaram neste tema através de treinamento e da certifica- 
ção em ITIL Foundationsº. Mas por que falar em próximos passos? Sim, 
porque o primeiro passo todos já deram. Foram em busca de conceitos, de 


ideias, de uma nova visão, de fundamentos. Mas e depois disso, quantos já se 


perguntaram: “Como prosseguir? Como chegar à minha empresa e colocar 
tudo isso em prática? Como convencer os outros de que algo precisa mudar? 
Por onde começar?” 

Realmente, um ambiente de Gestão de Serviços de TI não se constrói e não 
se mantém só com fundamentos. É preciso muito mais. Aí entra o segundo 
passo: a transmissão de conhecimentos relativos a “como fazer todos estes funda- 
mentos virarem práticas”. Algo que vamos chamar de “lições aprendidas” e que 
vamos procurar destacar ao final de cada tópico abordado. 

Falar em um “Guia de Implantação” pode dar a falsa ideia de que existe 
um roteiro infalível a ser seguido. Infelizmente, não poderemos apresentar 
este roteiro e lamentamos dizer que ninguém o fará, pelo menos com suces- 
so. Se assim fosse, na própria ITILº teríamos um livro dedicado ao tema. O 
que é possível fazer, entretanto, é repassar orientações sobre o que fazer e o 
que não fazer para estar sempre direcionado para o objetivo correto. Este é o 
sentido do Guia de Implantação que pretendemos apresentar. 

Esperamos conseguir apresentar uma nova perspectiva a você. Uma pers- 
pectiva baseada em experiências vivenciadas em treinamentos e em consul- 
torias executadas já há muitos anos. Não é preciso muito tempo de atuação 
nesta área para se perceber que o que deveriam ser “boas práticas”, ou até 
“melhores práticas”, podem rapidamente se transformar em “excelentes teo- 
rias”. Ideias todos concordam em absorver, conceitos todos se apressam em 
repassar, mas uma pequena inspeção mais detalhada em como todos estes 
fundamentos estão sendo usados de verdade denuncia que ainda falta muito 
a ser absorvido. É preciso viver no mundo real! É preciso sair da teoria dos 
livros e entrar nas práticas das organizações, pois lá tudo é diferente! E é 
nessa hora que se aprendem as lições que vamos tentar repassar. 

Este será nosso desafio e nossa motivação! Transformar fundamentos em 
práticas. Usar os fundamentos para construir sobre eles um monumento só- 
lido que resista ao tempo, como fizeram os egípcios com suas pirâmides. 
Aliás, esta é nossa primeira analogia. Iremos usar inúmeras durante o livro 
todo. Usaremos esta técnica para que possamos ver que, mesmo fora de nos- 
so mundo da TI, existem equivalências nas dificuldades, desafios, estratégias 


e ações que podem ser executadas. 


Você provavelmente encontrará neste material e nas analogias algumas 
respostas para as perguntas que já possui. Encontrará também muitas outras 
perguntas e talvez até acabe de ler o livro e tenha ainda mais a serem respon- 
didas. Ótimo. É assim que novas lições serão aprendidas. 

Usaremos uma trilha bastante clara baseada em sete passos. A metodolo- 
gia que acreditamos ser eficaz para implantar a GSTI se baseia nas atividades 


abaixo, que serão vistas a cada capítulo do livro: 


Preparar a empresa para a GSTI 


Preparar a Tl para a GSTI 


Construir um CMDB 


Construir um Catálogo de Serviços 


Construir Acordos de Nível de Serviço 


Construir uma Base de Conhecimento 


Implantar processos operacionais 
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Preparar a empresa para a GSTI 
Preparar a TI para a GSTI 
Construir um CMDB 
Construir um Catálogo de Serviços 


Construir Acordos de Nível de Serviço 


Construir uma Base de Conhecimento 


Implantar processos operacionais 


ste capítulo procura demonstrar que a implantação da gestão de serviços 
de TI requer muito mais do que o conhecimento técnico da TTILº e que 
esta iniciativa não pode ser conduzida exclusivamente pela TI. Muito mais 
importante do que uma TI com vontade de implantar a Gestão de Serviços 


é uma empresa receptiva a esta iniciativa. 


O QUE REALMENTE IMPORTA? 


O primeiro ponto que vejo como vital ao se discutir sobre ITIL® é jus- 
tamente procurar esquecer a própria biblioteca de melhores práticas (IT In- 
frastructure Library) e se focar no objetivo que ela visa atender: a Gestão de 
Serviços de TI. O próprio título deste livro é uma provocação. Queremos 
que, ao acabar de ler o livro, você pense: “Este livro não deveria ter este títu- 
lo, pois não fala de ITIL®; fala de gestão de serviços de TI.” E cada vez que 
você olhar para ele na sua estante vai se lembrar do que realmente é impor- 


tante. Se isto acontecer já teremos atingido nosso primeiro objetivo. 


GSTI 
Guia de 
Implantação 


ITILO 
Guia de 
Implantação 


Mas por que dizer que a ITIL® não importa? Ah, em tempo, usamos a 


denominação feminina para prefixar a palavra ITIL®, logo, sempre será “a 
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ITIL®”, “na TTILS”, “da ITIL®” e aí por diante. Isto porque pensamos nela 
como uma biblioteca. Mas poderia ser “o ITILº”, “no TTILº”, “do TTILº” 
etc., pois poderíamos estar pensando no framework, no paradigma. Mas isso, 
com certeza, também não importa. Vamos em frente. 

Por que a ITIL® não importa? A resposta é simples. Não importa porque 
é só um meio para se atingir um resultado e não o resultado em si. E no mun- 
do real o que realmente importa são os resultados (como veremos a seguir). 

Nos treinamentos de ITIL Foundationsº, em que participamos primeiro 
como alunos e depois como instrutores, e mesmo nas diversas publicações 
que vemos por aí afora, muitas pessoas acabam por se concentrar muito na 
biblioteca, nos livros, nas regras, nos conceitos (afinal, isso é o que vai ser 
cobrado na hora da prova de certificação), e menosprezam o resultado que 
efetivamente está por trás de tudo: a Gestão de Serviços de TI sendo feita de 
modo efetivo. 

E é aí que começam os problemas. Penso, às vezes, que o próprio proces- 
so de certificação, necessário sem dúvida para comprovar o conhecimento, 
possa ser para muitos a razão do desvio de propósito. Ou seja, eu estudo para 
passar na certificação e não para descobrir efetivamente um modo de obter 
resultados para minha empresa com aquilo que estou aprendendo. 

É claro que aqueles que após a certificação em fundamentos partirem para 
os próximos níveis de certificação e tiverem a oportunidade de chegar até, 
quem sabe, o nível de ITIL® Expert poderão reverter este desvio de propósi- 
to inicial. Deixarão, então, de pensar em “o que fazer” e começarão a pensar 
em “por que fazer” e “para quem fazer”. 

Isto significa um novo paradigma. Não se trata de discutir o que deve ser 
feito durante a gestão de incidentes, por exemplo, mas sim por que aquilo 
será feito daquele modo ou não, e para quem vai ser importante ou não. Isto 
me faz lembrar de uma questão que respondemos numa prova simulada para 
a certificação de Service Manager. Existia um case que precisava ser lido an- 
tes de responder a prova (sempre há um case!). Nele, tínhamos a informação 
de que uma empresa de transporte e logística possuía filiais em três lugares 
distintos: Hong Kong, Holanda e Canadá. A pergunta era simples: qual 


dentre os diferentes modelos de centrais de serviço você acredita que seja o 
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melhor — o local, o centralizado ou o virtual? Muita gente saiu respondendo 
a questão baseando-se somente na teoria que tinha aprendido. E muitos 
erraram. Não porque não sabiam a teoria sobre os modelos de service desk 
centralizado, local ou virtual, mas porque não pensaram que, baseado nas 
características da empresa apresentada no case, talvez o modelo que escolhe- 
ram não era o melhor. 

Este é só um exemplo que podemos transportar para a vida prática para 
nos lembrar de que toda a teoria do mundo não será suficiente se não formos 
capazes de entender as características e necessidades do ambiente onde ela 


terá que ser aplicada. Simples, não? 


LIÇÕES APRENDIDAS: Pense na Gestão de Serviços de TI antes de pensar na 
ITIL® e, só depois de saber onde está e aonde quer chegar, escolha um caminho, 
afinal: para quem não sabe para onde ir, qualquer caminho parece bom. 


ONDE APLICAREMOS A GESTÃO DE SERVIÇOS DE TI? 


Atuando no treinamento e na consultoria temos a oportunidade de co- 
nhecer diversas realidades: empresas pequenas, médias, grandes e muito 
grandes. Empresas públicas, privadas e mistas. Com gestão profissional, 
familiar ou até sem gestão formal. Descobre-se que a ITILº é uma só, 
mas que a Gestão de Serviços de TI em cada local diferente pode ser tam- 
bém diferente. Ouve-se, vez ou outra, alguém dizer: “Vamos implantar 
a ITIL® usando o método by-the-book.” Duas coisas assustadoras numa 
mesma frase! Primeiro porque não se implanta ITILº. Implanta-se a 
Gestão de Serviços de TI. E depois porque o método by-the-book parece 
ser a pior escolha possível. 

Deixar de respeitar a realidade na qual você está inserido e tentar “sacar 
de debaixo do braço os livros da ITIL®” para iniciar qualquer tipo de abor- 
dagem de implantação de Gestão de Serviços de TI é muito temeroso. Pode 
até dar certo, mas terá sido uma mera coincidência. Há uma chance de sua 


estratégia ter casado com a realidade sem os devidos cuidados ou sem uma 
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análise prévia. Mas qual é a chance de que isto ocorra? Uma em mil? Não 
se pode ter certeza. Mas como sabemos que a Lei de Murphy existe então 
é melhor não arriscar, pois é muito mais provável que a coincidência não 
ocorra. Se existem muitos caminhos a seguir, é melhor buscar orientação ao 


escolhê-los. 


Lembre-se de que as melhores práticas apresentadas na ITIL® são uma 
coletânea universal das práticas que demonstraram ser úteis para a obtenção 
de resultados na Gestão de Serviços de TI. Mas a questão é: De onde vieram 
estas práticas? À que tipo de empresas se aplicam? A que tamanho de empre- 
sas se aplicam? Por quanto tempo se aplicam? E lamentamos dizer: não há 


resposta para estas questões na própria ITILº. Só na vida real. 


LIÇÕES APRENDIDAS: Não caminhe num terreno que você não conhece. Ele pode 
estar cheio de armadilhas. Identifique seu ponto de partida, seu objetivo e os 
caminhos disponíveis. Identifique as armadilhas (ou pelo menos se prepare para 
elas). Só depois defina uma estratégia para sua viagem. 


COM QUEM ESTAREMOS TRATANDO? 


De certo modo esta questão nos remete para o começo do ciclo de vida da 


Gestão de Serviços. Mais precisamente ao processo de Gestão de Demanda, 
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de mapeamento do mercado, da identificação de oportunidades, executados 
durante o ciclo de Estratégia do Serviço. Veja bem, falando assim tudo parece 
teoria. Muita gente, mesmo depois de sair do curso de ITIL Foundations”, 
continua a pensar que o Service Strategy é coisa “de outro mundo”. Parece 
uma teoria pouco aplicável ao dia a dia. Parece que ninguém realmente faz 
isso na prática. Por que não ir direto para o Service Operation e implantar a 
gestão de incidentes? É tão mais simples. É tão mais frequente. E tão mais 
útil... 

Mas de que adianta definir um processo de gestão de incidentes se você 
nem sabe em que “terreno estará pisando”? Será que o seu processo de gestão 
de incidentes tem aderência aos requisitos e características da empresa em 
que você o estará aplicando? Uma empresa familiar, estatal ou multinacional 
poderá possuir características e também oferecer recursos e restrições dife- 
rentes que poderiam influenciar a própria definição dos processos. Isso sem 
falar nos procedimentos e instruções de trabalho. Percebe? Ignorar o am- 
biente em que você está inserido é um risco. E dos grandes. 


QUAIS CARACTERÍSTICAS PODEM INFLUENCIAR 
A IMPLANTAÇÃO DA GSTI? 


Estrutura 


Capacidade de 


Maturidade : : 
investimento 


aa Patrocínio 
organizacional 


Recursos 
humanos 


Resistência a Experiências 


prévias 


mudanças 


Maturidade 


Poderíamos imaginar que quanto mais maturidade em TI uma orga- 
nização possua, mais fácil seria agregar a GSTI ao ambiente. Porém, isso 


nem sempre será verdade. Muitas organizações com grande vivência em 
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TI, ou que já possuem TI há muito tempo, podem não necessariamente ter 
grande maturidade, pois podem ainda estar presas a paradigmas tradicio- 
nais herdados no transcorrer de suas histórias. Isso indica que a maturidade 
deve ser avaliada com base em outros parâmetros além do tempo do uso de 
recursos de TI ou do tempo em que exista um departamento ou diretoria 
de TI operando no ambiente. 

Para fins de GSTI, a maturidade que se espera identificar numa organi- 
zação está associada à existência de um ambiente de gestão ou governança 
de TI, que use ou não os conceitos de GSTI, mas que tenha, efetivamente, o 


reconhecimento da organização. 


Resistência a mudanças 


Alguns tipos de organização podem ter maior ou menor adaptabili- 
dade a mudanças. Normalmente aquelas focadas em inovação e busca de 
resultados estarão mais abertas às mudanças que a GSTI estabelecerá. Já 
as tradicionalistas ou atuantes em segmentos pouco competitivos podem 
ser mais resistentes à busca de mudanças em processos que hoje já este- 


jam em operação. 


Estrutura organizacional 


O tamanho, a complexidade e o modelo de gestão de uma organização 
poderão influenciar positiva ou negativamente na implantação da GSTI. 
Por exemplo, uma empresa com estrutura de gestão familiar, que atue em 
muitos segmentos de negócio, com grande quantidade de departamentos 
envolvidos em sua operação, poderá gerar maior complexidade para o 
processo de GSTI do que uma empresa com gestão profissionalizada, 
atuando em uma única área de negócio e com poucos departamentos 


envolvidos. 
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Recursos humanos 


A quantidade, o nível, a capacitação, o modelo de contratação e a gestão, 
entre outros fatores, podem influenciar também na facilidade que teremos 
para disseminar e operacionalizar os conceitos de GSTI através da organiza- 
ção. Veremos mais à frente que grande parte do sucesso da implantação da 
GSTI não se deve aos esforços e méritos da própria TI, mas à participação 


de stakeholders nos processos que a TI defina. 


Patrocínio 


Como toda mudança que se proponha a uma organização, a implanta- 
ção da GSTI também irá requerer boa cota de comprometimento da alta 
direção. Caso nosso plano seja uma iniciativa isolada da TI, sem endosso da 
alta direção, teremos poucas chances de conseguir atingir nossos objetivos. 
Poderemos até ter a TI praticando gestão de serviços, mas nossos clientes, os 


principais beneficiados, não comprarão nossas ideias. 


Experiências prévias 


Caso seu plano de implantação de GSTI esteja sucedendo uma iniciativa 
anterior mal conduzida, você, com certeza, terá focos de resistência já for- 
mados. À resistência a mudanças é um fator previsto no projeto. Faremos 
todos os esforços para minimizá-la, porém, se ela já estiver instalada, teremos 
que ser ainda mais convincentes dos benefícios e resultados que poderemos 
produzir. Neste caso, contar com o apoio e a experiência externos pode ser 


ainda mais importante. 


Capacidade de investimento 


Uma ideia que defendemos é que muitas pessoas fazem o curso de ITIL 


Foundationsº motivados pela busca de melhorias no seu service desk. Estão 
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até dispostos a implantar a gestão de incidentes, de problemas, de cumprimen- 
to de requisições, e por aí afora. Tudo para ter um service desk funcionando 
melhor. Mas, infelizmente, somos obrigados a dar uma má notícia: melho- 
rias de resultados no Service Operation requerem “um certo investimento” 
de tempo, recursos e atenção nas fases anteriores do ciclo de vida do serviço, 
principalmente na fase de estratégia do serviço. É lá que conheceremos nossos 
clientes. E, afinal, que tipo de service desk é este que você quer que seja melhor 
se você nem conhece bem o seu cliente? Logo, mãos à obra. 


LIÇÕES APRENDIDAS: Se você deseja benefícios na operação de seu service 
desk (e parece que este é um objetivo em comum), então comece do começo! 
Conheça seu cliente. Mapeie suas demandas (atendidas e não atendidas). Identi- 
fique os recursos que você tem disponíveis para produzir e manter serviços de TI. 
Só depois defina processos de operação. 


COMO SERÁ O RELACIONAMENTO ENTRE AS PARTES? 


Quando falamos em Gestão de Serviços de TI, pressupomos a ideia de 
que há um relacionamento entre o fornecedor e o cliente do serviço. Isso 
parece trivial. Mas não é. Parece trivial para nós que somos os fornecedores e 
estamos estabelecendo regras para os nossos clientes. Mas e eles? Como nos 
enxergam? Como enxergam este relacionamento? 

Na verdade, a questão é bem mais complexa do que só estabelecer o pro- 
cesso de relacionamento. Muita gente, ao conhecer a ITIL®, tem a impressão 
de que o que realmente fará a diferença será estabelecer processos novos. E, 
por um lado, não estão errados, pois realmente o ponto-chave é a mudança 
de processos. Mas também, por outro lado, a maior parte das pessoas erra ao 
pensar que os processos deverão ser definidos de dentro para fora, ou seja, de 
dentro da área de informática para as outras áreas da organização. 

Aqui, vamos usar novamente uma analogia (e serão muitas durante o li- 
vro, pois não podemos deixar de pensar que as lições do mundo real devam 


ser aplicadas ao nosso pequeno mundo abstrato da TTIL*). Já contamos esta 
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história várias vezes. Até já a publicamos. Então, perdoem-me os que já a 
conhecem, mas ela é fundamental neste ponto. Chama-se: “O restaurante 


mudou.” E é, mais ou menos, assim: 


Um cliente habitual, acostumado a frequentar um pacato restaurante ali na esqui- 
na, brigou, outro dia, com o proprietário. Armou a maior confusão e prometeu que 
nunca mais comeria lá. 


O MOTIVO: Ele fez o que fazia todo os dias. Entrou no restaurante, foi até a mesa 
de sempre, lá no fundo, e ficou esperando pelo garçom que sempre lhe atendia. E 
esperou, esperou, esperou, mas nada de vir alguém lhe atender. Olha daqui, olha 
de lá e nada. Depois de um tempo ele levantou, mandou chamar o dono do res- 
taurante e disse que era um desaforo ver tanta gente em volta saboreando seus 
deliciosos pratos, mas ele estar lá esquecido. Confusão armada, saiu sem tempo 
de o proprietário fazer qualquer coisa. Cliente perdido. 


A EXPLICAÇÃO: Um dia antes, o proprietário do restaurante, querendo se moder- 
nizar, seguir tendências, criar um processo novo de atendimento, obter melhores 
resultados e oferecer um serviço diferenciado, implantara o sistema de self-ser- 
vice em substituição ao custoso sistema de pratos “a la carte” que adotava até 
então. Pequeno detalhe: não comunicou isso ao habitual e antigo cliente. Não fez 
uma pesquisa prévia com os clientes. Não questionou sobre seus costumes e 
interesses. 


RESULTADO: Cliente perdido. 


Esta história demonstra em poucas palavras a questão das mudanças de 
processos feitas de dentro para fora, sem participação dos clientes no mo- 
mento certo e na medida certa. Não queremos defender a tese de que eles 
terão que definir os processos e que a TI deverá se adaptar ou que os clientes 
possam impedir que processos definidos pela TI sejam implantados. Não. 
Mas queremos insistir que conhecer o “terreno onde vamos pisar” é um pon- 
to essencial para o sucesso de implantação de novos processos baseados na 
ITILº, ou mesmo baseados em qualquer outra abordagem. 
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Se voltarmos um pouco aos conceitos de processos apresentados no curso 
de fundamentos de ITIL®, veremos que existem claramente pontos que con- 


firmam esta tese. Vejamos alguns: 


PONTO NÚMERO 1. Um processo requer entradas e produz saídas baseadas 
em atividades que são executadas por agentes. Neste contexto, podemos per- 
ceber que a organização como um todo, e não só a TI, pode ser o fornecedor 
de entradas, recebedor de saídas e o agente de transformação. 


PONTO NÚMERO 2. O mapeamento de processos pode ser feito através de 
uma matriz RACI (lembra-se do conceito?) na qual, para cada atividade, 
podemos elencar as áreas ou papéis que as executam. E aí, é claro que nova- 
mente teremos vários agentes de fora da TI citados, seja como Responsáveis, 


Accountables, Consultados ou Informados. 


PONTO NÚMERO 3. Cada processo da ITILº, entre os mais de 20, é di- 
recionado, em última instância, para a realização de um grande processo 
chamado Gestão de Serviços de TI, e este, por sua vez, tem uma importante 
finalidade: prover serviços de TI alinhados com as necessidades dos clientes, 
de modo contínuo, com garantias, no tempo certo e uso racional de recursos 


continuamente aperfeiçoados. 


FORNECEDORES, PROVEDORES DE 
SERVIÇO (INTERNOS E EXTERNOS) 


PROCESSO DE 
GESTÃO DE 
SERVIÇOS DE TI 


(D 
OUTROS STAKEHOLDERS 
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Muitos outros pontos estudados convergem para um único ponto: o clien- 
te. À própria Gestão de Serviços de TI poderia se chamar Gestão de Serviços 
para Clientes de TI. Só chamar de Gestão de Serviços de TI nos parece de- 
notar algo muito voltado para dentro da TI. Como se ela fosse gerenciar os 
serviços porque é bom para ela. E não é essa a visão correta. A TI deve geren- 
ciar os serviços porque isso é bom para o cliente. Porque se ela não fizer isso, 
o cliente será afetado. Porque se ela fizer isso o cliente será beneficiado. 

É importante que se destaque que não estamos só falando em oferecer 
um melhor suporte para nossos clientes, apesar de muita gente se fixar nes- 
sa ideia. Pode ser um dos objetivos, mas não deve ser o único. Em muitos 
treinamentos já encontramos vários exemplos de pessoas que parecem que 
gostariam que o curso já começasse no tópico de Service Operation. As fases 
anteriores do ciclo de vida parecem enfadonhas, um desperdício de tempo, 
temas abstratos sem aplicação prática, e por aí afora. Você já conheceu al- 


guém assim? 


LIÇÕES APRENDIDAS: Coloque o cliente em primeiro lugar. Crie tudo pensan- 
do nas melhorias que ele deseja e pode obter. Mesmo nas mudanças de pro- 
cessos internos da TI procure identificar como esses processos irão contribuir 
para a satisfação dos clientes. E apresente sempre tal ponto de vista quando 
se relacionar com eles. Será a sua chance de engajá-los definitivamente nos 
processos. Ninguém faz nada se não tiver benefícios em troca. Encontre-os e 
os apresente. 


O QUE A ORGANIZAÇÃO ESPERA DA TI REALMENTE? 


Pense: Se você estivesse procurando um hotel para se hospedar em uma 
viagem de turismo com a família, qual seria o critério de seleção que você 
utilizaria para escolher o melhor? Aquele que tem a melhor equipe na recep- 
ção, pronta para resolver todos os seus problemas rapidamente (mesmo que 
surjam muitos durante sua estada) ou aquele que oferece atrações, facilida- 


des, infraestrutura, conforto, segurança e satisfação a um preço justo? Você 
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é o cliente e o hotel o fornecedor de serviços. Eles não têm ITIL® lá. Mas 
poderiam ter. E funcionaria. 

Será então que estas mesmas expectativas também podem estar sendo 
criadas em relação a TI pelas nossas organizações? Será que somos ob- 
servados como fornecedores de serviços que devem oferecer muito mais 
do que atendimento com rapidez? Muito provavelmente. Até poderíamos 
dizer que certamente eles esperam muito mais, apesar de às vezes não nos 


parecer que isso seja verdade. Dentre os principais resultados esperados 


podemos citar: 


Melhoria na 
utilização dos 
recursos 


Redução do 
tempo de 
atendimento 


Redução das 
interrupções 
dos serviços 


Melhoria dos 
serviços 
oferecidos 


Melhoria dos serviços oferecidos 


Apesar de o próprio conceito de serviço de TI ainda não estar corre- 
tamente estabelecido em grande parte das organizações (por enquanto 
vamos desconsiderar este fato, deixando-o para ser tratado no próximo 
capitulo), formal ou informalmente as organizações esperam que a TI 
ofereça mais. Mais recursos, mais facilidades, mais tecnologia, mais se- 
gurança, mais resultados. 

Você se lembra da analogia do hotel? Todos esperam como clientes que o 
fornecedor ofereça mais e atenda ou supere suas expectativas. Que surpreen- 
da. E não seria diferente em relação aos serviços oferecidos pela TI. Se você 
perguntar para qualquer pessoa em qualquer empresa sobre o que eles acham 
da TI, poderá até encontrar respostas como “muito boa” e talvez até “exce- 
lente”. Mas se, logo em seguida, perguntar: “Você acredita que a TI poderia 
melhorar?” ou “Sua área ainda tem alguma demanda não atendida pela TI?”, 
vai sempre receber a mesma resposta: “Sim!” 

Isso não significa que não somos muito bons ou excelentes. Significa que para 


cada demanda atendida, outras demandas surgem. É como no hotel. Por mais 
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que ele ofereça, sempre alguém vai se lembrar de um item adicional. Coisas da 
natureza humana. Assim sendo, podemos assumir que vamos sempre encontrar 
algum tipo de demanda reprimida, explícita ou não. A questão então será definir 
se devemos, podemos ou queremos atender a estas demandas e como as atende- 
remos. Mas isso é assunto para mais tarde. Por enquanto vamos nos ater ao fato 


da existência da demanda por melhoria nos serviços oferecidos. 


Melhoria na utilização dos recursos 


Se os conceitos de serviços de TI podem não estar bem claros para muitos 
na organização, não podemos dizer o mesmo com relação ao conceito de re- 
cursos. Todos compreendem e reconhecem sua existência e, principalmente, 
sua ausência. Talvez muito mais a ausência. 

Aqui, mais uma vez, os conceitos vistos no curso de ITIL Foundations? 
são importantes. São estes recursos que compõem os Ativos de Serviços. 
São eles: os recursos financeiros, a infraestrutura, as aplicações, as informa- 
ções e as pessoas. Imagine agora que, mesmo sem conhecer nada de ITIL®, 
qualquer gestor de outra área, como a área de Recursos Humanos ou de 
Produção Industrial, pode facilmente perceber que o gestor de TI detém 
estes recursos para aplicá-los na geração de novos serviços e na operação dos 
serviços já existentes. 

Não há como negar que a correta administração dos recursos realmen- 
te vai produzir melhores serviços e deixar nossos clientes mais satisfeitos. 
Também não há como negar que os recursos, sejam quais forem, são sempre 
finitos e restritos. E aí, erroneamente, muitas vezes a responsabilidade de 


“atender a todos independentemente das restrições” recai sobre a TI. 


Redução do tempo de atendimento 


Vamos imaginar que estamos fazendo aquele exercício de associação de 
palavras no qual um interlocutor fala uma palavra e você logo em seguida 
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responde outra, trazendo de sua mente um conceito intimamente ligado ao 
outro. Boa parte das pessoas envolvidas com processos de atendimento a 


clientes teria a seguinte experiência: 


INTERLOCUTOR: Reparo VOCÊ: Prazo 
INTERLOCUTOR: Recuperação VOCÊ: Prazo 
INTERLOCUTOR: Atendimento VOCÊ: Prazo 
INTERLOCUTOR: Mudança VOCÊ: Prazo 


Encerra-se a sessão e o interlocutor estará certo de que você tem uma 
ideia fixa: prazos. Principalmente aqueles prazos que não são atendidos. Tal- 
vez você ainda esteja em um estágio anterior ao dos mais estressados, que, 
para as quatro palavras acima, teriam respondido “Atrasos”. 

Com ou sem exercício de associação, não podemos deixar de reconhe- 
cer que a palavra “prazo” se incorporou definitivamente ao vocabulário dos 
provedores de serviço. O compromisso, a responsabilidade, a produtividade, 
a eficiência e tantas outras características acabam sendo muitas vezes tradu- 
zidas em prazos. É uma métrica fácil de ser monitorada, logo, fácil de ser 
aplicada. E isso muitas vezes acaba sendo transmitido pela TI para a orga- 
nização. E o que acontece, então? Na próxima rodada de negociações entre 
a TI e seus clientes, o critério “prazo” tomará proporções desproporcionais 
e será fortemente associado ao critério “qualidade”, gerando uma linha de 


raciocínio equivocada: 


DENTRO DO PRAZO > RESULTADO DE BOA QUALIDADE 


FORA DO PRAZO 2 RESULTADO DE MÁ QUALIDADE 


Certa ou errada, a expectativa de redução contínua dos tempos de aten- 
dimento acaba por se transformar em um fator que a TI terá que saber tratar 


com iniciativas e com mudanças de paradigmas. 
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Redução das interrupções dos serviços 


Ninguém gosta de ficar sem o recurso ou o serviço que contratou ou que 
estava recebendo. Podemos até não ter algo, mas, depois que temos, ficamos 
com a sensação de que não poderíamos mais viver sem. Coisas da natureza 
humana. 

Não seria diferente com relação aos clientes da TI. Portanto, planeje-se 
para oferecer serviços que tenham garantia. Garantia de continuidade, ga- 
rantia de disponibilidade, garantia de capacidade, garantia de segurança etc. 
Perceba mais uma vez que não se trata de oferecer continuidade, disponibi- 
lidade, capacidade e segurança porque a ITILº recomenda, mas de oferecer 
aquilo que o cliente requer. Precisamos oferecer aquilo que atende às expec- 


tativas do cliente e do negócio. 


LIÇÕES APRENDIDAS: Não se deixe levar somente pelas cobranças de prazos e 
não acredite que entregar um bom serviço é somente não ter chamados atrasados 
na sua fila de atendimento. Estimule seu cliente a expor suas demandas. Mante- 
nha um relacionamento focado em resultados. 


DE QUEM SÃO AS EXPECTATIVAS? 


Comentamos até aqui quatro expectativas reconhecidas nos ambientes 
corporativos e, durante os exemplos, falamos em clientes. Clientes que não 
querem ficar sem os serviços oferecidos, querem prazos menores, recur- 
sos mais bem aplicados, e por aí afora. Falamos também sobre a natureza 
humana representada em alguns comportamentos. Porém, é importante 
destacar neste ponto, que a figura do cliente deve ser representada pela área 
de negócio que utiliza um serviço de TI e que a figura do usuário deve ser 
representada pelas pessoas, exercendo funções e papéis nos processos de 
negócio. 

Logo, quando se fala em expectativas, deveríamos sempre nos focar nas 


expectativas, necessidades e requisitos das áreas de negócio. Nunca nas 
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pessoas, pois estas vêm e vão, mudam de ideia, são instáveis, têm gostos e 
vontades. Áreas de negócio têm finalidades, objetivos, demandas, requisitos 
de operação e fluxos de trabalho. Isso é estável, isso pode ser planejado, mo- 
nitorado e avaliado. 

Existem muitos ambientes em que muitas iniciativas de implantação de 
processos ITIL® tiveram dificuldades de produzir os resultados esperados 
porque muita coisa se baseava no pessoal e não no funcional. Atenção: se 
você não consegue fazer com que a organização exponha suas necessidades 
e demandas baseadas em critérios de negócios sem que isso se transforme 
em um pedido pessoal do “Sr. João do RH”, então repense sua estratégia de 
implantação de ITIL® na organização. 

Sem uma visão focada em clientes corporativos (e não pessoais), não ha- 
verá compreensão de vários outros pontos importantes tais como interrup- 
ção de um serviço, restabelecimento de um serviço, nível de serviço (e não 
estamos falando de prazo, mas de nível de serviço num modo abrangente), 
solução de contorno e muito mais. Não é só a TI quem deve compreender 


estes conceitos. E principalmente o cliente. 


LIÇÕES APRENDIDAS: As demandas e necessidades terão uma forte tendência 
de deixarem de ser corporativas (ou de áreas de negócio) e se transformarem em 
demandas pessoais. Tome cuidado. Procure sempre mostrar o que cada área de 
negócio precisa e o que a TI pode oferecer, porém mantenha-se sempre focado 
no negócio. 


QUE MUDANÇAS OS CLIENTES NA ORGANIZAÇÃO PRECISAM 
FAZER PARA ABSORVER A GESTÃO DE SERVIÇOS DE TI? 


Todo mundo quer ir para o céu, mas ninguém quer morrer. 


Consultas na internet apontam que esta frase é de um autor desconheci- 
do. Mesmo sem saber se ele teve experiências com processos de atendimento 


de clientes, podemos imaginar que, se fosse o caso, ele manteria a opinião. 
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A verdade é que os clientes da TI desejam ter suas expectativas atendidas. 
E atender as expectativas, para eles, parece ser uma responsabilidade exclu- 
siva do fornecedor. Coisa do tipo: “Eu preciso e você pode fornecer, logo, 
forneça!” Parece até fazer sentido, pois se nós somos os fornecedores e eles 
são os clientes, então devemos sempre atendê-los. Seria este o nosso papel? 
Talvez não. 

Na prática, o que se observa em ambientes que continuam a ter clientes 
com esta visão é que, por mais que a TI se esforce, as demandas acabam sem- 
pre sendo maiores do que as ofertas. Bem, na verdade esta regra é universal! 
Não importa o quanto se ofereça, alguém sempre irá desejar mais... 

Cada um de nós, como clientes, devemos entender que o relacionamento 
entre as partes é interdependente. A cada ação corresponderá uma reação. 
Sábio Newton! Sim, hoje ninguém dúvida disso, mas muitos se esquecem. 
Quem já não presenciou um cliente procurando se impor, usando prerroga- 
tivas pouco consistentes para ser atendido antes do que outro? Ou quem já 
não percebeu que seu cliente abusa da boa vontade da equipe? E quem ainda 
não descobriu que seus clientes são muitas vezes “difíceis de obedecer”? Pois 
é. São todas características típicas de um relacionamento cliente-fornecedor 
desajustado, principalmente quando o assunto é TI. 

Vamos analisar cinco pontos em que as corporações e suas áreas de ne- 
gócio precisam focar para que o relacionamento com a área de TI realmente 


funcione: 


Seguir Receber Adotar as Ter visão Focar nos 
regras atendimento soluções e corporativa resultados 
padronizado orientações 


recebidas 


Seguir regras 


Não deveria ser necessário dizer que, para que uma relação funcione bem, 
devem existir regras e que as regras têm de ser cumpridas. Isto é a lei que 


rege as sociedades, desde as formigas até os humanos ditos inteligentes. Se 
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a formiga operária não seguir as regras da comunidade (consciente ou in- 
conscientemente), ela deixa de ser uma operária. Se o professor não seguir as 
regras, ele deixa de ser professor. E se o cliente não seguir as regras, ele deixa 
de ser cliente, na acepção mais profunda da palavra. 

Mas o que deveria ser óbvio passa por vários momentos nebulosos quando 
começamos a analisar os processos de atendimento a clientes que a TI têm 
com a corporação. Não porque a TI não tenha regras ou porque as regras 
sejam ruins, mas porque elas acabam sendo burladas, esquecidas, menos- 
prezadas, desprezadas, derivadas. E aí o relacionamento se deprecia, como 
qualquer outro. 

As melhores práticas defendidas pela ITILº são em grande parte orien- 
tadas por regras. Muitos dos conceitos novos que precisam ser absorvidos 
são regras. Muitos processos passam a ser realizados de modo diferente. Isto 
também cria regras. Muitos papéis, atribuições e funções passam a ter par- 
ticipação específica em atividades. Mais regras. Mas, espere aí. Então não 
bastaria que a TI seguisse estas regras e tudo funcionaria muito bem? Não. 
Isto não é o suficiente. 

Lembre-se de que em cada nova atividade de cada novo processo envol- 
vendo cada novo conceito teremos um velho elemento: o cliente. E muitas 
vezes este não segue as regras. E o jogo precisa dos dois times seguindo as 
mesmas regras para dar certo. Imagine se em um jogo de futebol um time 
pudesse ter 11 jogadores e o outro só 5. Para um vale a regra do futebol de 
campo e para o outro vale a regra do futebol de salão, mas o jogo é um só. No 
mesmo campo e no mesmo horário. Não tem chance de dar certo! 

Mas por que o cliente seguiria as regras se, muitas vezes, sem elas tudo 
parece mais fácil? Vamos ver um exemplo. 

Regra: para que um cliente seja atendido deve haver a formalização do pedido 
registrado previamente em um sistema. Depois o atendimento será feito. 

Qual a chance de que todos os clientes respeitem esta regra? Depende. Se 
o cliente for o departamento de produção solicitando a criação de uma nova 
vaga no seu quadro funcional para o fornecedor de serviços, que é o RH, po- 
deríamos dizer que a chance de isso acontecer é de 100%. Já se o pedido esti- 


ver sendo feito pelo RH para a área financeira e o assunto for uma liberação 
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de duas diárias para viagem de um diretor, também poderíamos apostar que 
a chance de que tudo seja registrado primeiro para depois ser atendido seja 
de 100%. 

Agora, se o pedido for de qualquer outra área para a TI solicitando que 
seja feito um backup dos dados do notebook do diretor e que uma cópia dos 
dados seja enviada para a sua secretária, podemos ter nossas dúvidas sobre 
o percentual. Muito provavelmente não seria 100%. Alguma coisa abaixo 
disso, variando conforme o tipo de empresa, tamanho, experiências ante- 
riores, existência de uma política de segurança da informação, entre outros 
fatores. 

O que queremos demonstrar com esse exemplo? Que podem existir pro- 
cessos em diversas áreas. Que podem existir regras em várias áreas. Que po- 
dem existir pessoas subordinadas às regras que outros criaram (seguir as pró- 
prias regras é fácil, não é mesmo? Duro é seguir a dos outros!). Mas, às vezes, 
parece que as regras criadas pela TI podem ser tornadas opcionais em uma 
ou outra situação conforme a conveniência, conforme quem está pedindo, 
conforme a pressa, e por aí vai. 

Certo, sabemos que isso acontece. Mas como reverter este quadro? Parece 
que só há dois modos de convencer as pessoas a colaborarem: se elas virem 
que vão receber vantagens assim ou se perceberem que vão encontrar restri- 
ções se não fizerem o que está determinado. Simples, não? Como diriam os 
mais objetivos: “Por bem ou por mal.” Melhor que seja por bem. 

Isso não quer dizer que precisamos “comprar as pessoas” ou “punir as 
pessoas”. Talvez as melhores expressões fossem “motivar as pessoas” ou “criar 
restrições às pessoas”. 

Veja se não é o que ocorre hoje em outros segmentos de serviços: no setor 
bancário, por exemplo, os bancos remodelaram o processo de atendimento 
dos clientes nas agências. Existe agora o autoatendimento nos caixas eletrô- 
nicos, mas também continua a existir o atendimento presencial nos caixas 
pessoais. Definiram-se, então, novas regras de atendimento que todos temos 
que seguir. Uma delas é que, por exemplo, saques de pequenos valores de- 
vem ser feitos no caixa automático enquanto saques de grandes valores de- 


vem ser feitos no caixa pessoal, inclusive com agendamento prévio. Criou-se, 
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portanto, uma regra que poderia ser implantada com dois métodos: “Pelo 
bem ou pelo mal.” 

Pelo lado do “bem”, ou através da motivação das pessoas, o banco procu- 
rou mostrar aos clientes que sacar pequenos valores é muito mais rápido no 
caixa automático, que o caixa automático é seguro, que existem 10 deles em 
cada agência, que existe uma mocinha lá, supersimpática, só para lhe ajudar, 
que não custa nada, e por aí afora. É o método do incentivo. Sim, mas você 
poderia não se convencer por esta via. 

Você poderia ser um daqueles teimosos que insistem em entrar na fila 
do atendimento pessoal para sacar R$10 para comprar uma revista. Então 
aplicaram o processo do mal, ou da restrição. Você poderá entrar na fila do 
atendimento pessoal, mas antes vai ter que passar por uma porta giratória 
e deixar todos os seus “metais” por lá. Depois vai ter que pegar uma senha 
(existem bancos que possuem três tipos de senha, logo, primeiro você tem 
que descobrir se a sua é a preta, a vermelha ou a azul...), depois vai ter que 
ficar olhando para aquele painel para ver se a senha é a PR-0001 ou a VE- 
0001 ou a AZ-0001. Não basta ser a 0001. Depois vai ter que esperar aquele 
office-boy que está na sua frente fazer o pagamento de 20 contas diferentes, 
receber o troco, conversar com a menina do caixa, e então... Chegou a sua 
vez e o caixa vai sair para almoçar. Você terá que esperar abrir o caixa do lado 
para então pegar os seus R$10. 

Percebeu? Dá para convencer qualquer pessoa a mudar de processo de 
saque de pequenos valores, pelo bem ou pelo mal. Nos dois modos você 
prestará o serviço. Não se pode impedir que as pessoas escolham. Ofereça 
alternativas e quem deverá escolher é o cliente. Ele precisa entender o que 
é melhor para ele. Se ele é um senhor aposentado que quer mesmo passar o 
dia no banco conversando com os “novos conhecidos da fila”, ótimo. Mas, 
de qualquer modo, ele terá que seguir as regras. Nem da fila prioritária para 
idosos ele irá se livrar! São regras. Têm que ser seguidas. 

Logo, convencer os clientes a seguirem nossas regras poderá requerer es- 
tratégias do bem e do mal. Pense nas suas. Tenho certeza de que você conse- 
guirá apresentar benefícios e restrições que possam fazer com que as pessoas 


decidam. 
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Por exemplo, você quer que todos abram chamados pela web e deixem de 
mandar e-mails para sua equipe? Mostre para seu cliente, pelo lado do bem, 
que a abertura de chamados pela web é mais ágil, que o sistema preenche 
vários campos automaticamente, que imediatamente ele vai saber que o cha- 
mado já está atribuído para uma equipe, que ele vai receber uma prioridade 
sempre justa e não vai depender de critérios externos de classificação, que ele 
vai poder registrar solicitações mesmo após as 18h e elas serão automatica- 
mente notificadas para os técnicos de plantão. 

Já se seu cliente não se adaptar ao método do bem, você pode usar o 
método do mal. Mostre que, se ele continuar a enviar e-mails pedindo su- 
porte, estes e-mails serão lidos somente a cada 30 minutos quando a equipe 
realizará o processo de triagem de e-mails programados nestes intervalos de 
tempo (é prerrogativa sua criar horários assim como os bancos fazem para o 
atendimento pessoal). 

Mostre a seu cliente que, ao enviar o e-mail, ele terá que ficar esperando 
outro e-mail de confirmação com o resultado da triagem de seu chamado e 
que, se ele não concordar com qualquer classificação feita pela equipe, deverá 
esperar outro turno de 30 minutos para enviar complementações dos dados 
faltantes ou para reclamar. 

Mostre que um e-mail pode não chegar, que o retorno de confirmação 
pode também não voltar, cair na caixa de spam, ou coisa parecida. Mostre 
que o tempo que se gasta para ler um e-mail e transformá-lo em um chamado 
(esperar os 30 minutos, depois ler, entender, resumir, digitar, copiar e-mail e 
anexar ao chamado) será descontado do tempo de início do atendimento do 
chamado, pois o prazo só começa a contar quando o chamado está realmente 
aberto. E por aí vai... 

Os clientes podem se convencer sozinhos de que uma regra é boa para 
ele. Mas ela tem que ter sido criada com este objetivo. Não vale você criar 
uma regra qualquer que só vai atrapalhar o cliente e que não agregue nada de 
benefício a ele, e tentar impô-la. 

O que você apresentaria pelo lado do bem ou como incentivo quando fosse 
defender a ideia? Diria que ela é boa para a TI? Evite este caminho. Mas, e se 


mesmo com todo o seu esforço, ainda assim o cliente não seguir as regras (sim, 
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isso acontece...)? Existem pessoas que nem pelo bem, nem pelo mal compreen- 
dem que precisam cumprir um papel num processo e se negam a cooperar. 

Neste caso, só resta criar o plano B, ou seja, criar uma regra para quan- 
do a regra não for seguida. E aí quem deve cumprir esta regra é você. A 
regra diz que as pessoas precisam abrir um chamado para serem atendidas? 
Os clientes não abrem? Então vamos criar um histórico dos atendimentos 
feitos sem um chamado aberto ou vamos abrir nós mesmos os chamados 
faltantes. 

Podemos também criar uma “regra” que diga que poderemos “esquecer” 
dos chamados não registrados e que não poderemos ser responsabilizados 
por isso, afinal, não há mesmo como provar que alguém pediu algo, certo? 
A “falta de memória” pode ser um sintoma aceito na equipe de suporte. A 
solicitação não está registrada? Não faremos. Somos muito esquecidos. 

Querem lhe cobrar prazos? Do quê? Não há registro da data do pedido, 
logo não existe um prazo conhecido. Sempre existirá um jeito de convencer 
as pessoas, mas não pense que será fácil. Existem muitos perfis de clientes 
diferentes a serem entendidos e atendidos e nem sempre nossas regras se 


adaptarão a todos eles. 


LIÇÕES APRENDIDAS: Utilize o “método do bem e do mal” para justificar as regras 
que você estabelecer, mas coloque sempre o cliente em primeiro lugar. Coloque- 
se no lugar dele, que terá que absorver a nova regra, e procure pensar em por 
que você a adotaria. Descubra previamente as resistências e prepare argumentos 
concretos (baseados em benefícios). Se você não conseguir convencer a si mes- 


mo, então será muito mais difícil convencer os outros. 


Receber atendimento padronizado 


Todos desejam qualidade no atendimento. Todos desejam rapidez no 
atendimento. Mas basta falarmos em padronização, critérios automáticos de 
estabelecimento de prioridades, execução de procedimentos padrão, atendi- 
mento de requisitos, coleta de informação e outros itens para que os clientes 
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digam: “Mas precisa de tudo isso? Não dá para ir fazendo o que eu pedi como 
era antes e depois a gente cumpre estas etapas burocráticas?” 

Se o cliente quer o melhor atendimento, então o melhor para ele pode 
parecer ser o atendimento personalizado. Muito se discute sobre a perso- 
nalização e a padronização. Alguns defendem que personalizar é tornar o 
atendimento mais humano, mais pessoal. Tem lá sua razão. Mas e na hora 
em que aquela pessoa que sempre lhe atendeu não estiver disponível? O 
que você quer então? Esperar por ela ou ter outro que lhe atenda “tão bem 
quanto ela”? 

Se você respondeu que deseja que outro lhe atenda “tão bem quanto”, en- 
tão você é do time que aposta na padronização. Você quer que o seu padrão 
seja seguido. Se um atendente lhe atende sempre como um “rei” e lhe dá 
todas as “regalias”, mas outro atendente não lhe dá qualquer benefício extra, 
você não vai gostar do atendimento personalizado que cada um lhe dá. Se 
todos os atendentes lhe atendessem sempre como “rei”, você seria o primeiro 
defensor do padrão “atendimento modelo rei”, ou não? 

A pior coisa para o cliente em não ter um atendimento padronizado (e, 
como dissemos, devemos sempre pensar no cliente na hora de tomarmos 
nossas decisões) é ele não saber como será atendido. Não poder ter uma 
expectativa. O atendimento será sempre uma surpresa, e o pior é que poderá 
ser uma surpresa desagradável. 

O cliente precisa entender (de novo usando o método do bem ou do 
mal) que a padronização é boa para ele. É certo que ela é boa também 
para a TI, pois permite a rotatividade de equipes, a entrada mais fácil de 
novas pessoas no time, facilita a previsão de recursos a serem alocados 
nos processos e coisa e tal. Mas ela é boa, principalmente, para o cliente 
que sabe o que esperar do processo: ou sempre o atendimento de “rei” ou 
sempre o de “não rei”. 

O cliente precisa entender que sem padronização não poderemos avaliar, 
monitorar, medir, treinar, aperfeiçoar. Lembre-se do ciclo de vida do serviço 
chamado “Melhoria continuada do serviço”. Pois é, a melhoria da qualidade 
dos serviços é uma expectativa do cliente, mas, para obtê-la, ele precisa pri- 


meiro adaptar-se a um modelo padronizado. Como melhorar um processo 
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ou um serviço se sua entrega é feita de modo imprevisível e não repetível? 


Melhorar o quê, quando, onde, para quem, como? 


LIÇÕES APRENDIDAS: Vários programas de qualidade, como a ISO-9001, ado- 
tam padronização. Se a gestão de serviços de TI visa melhoria no atendimento 
então não seria justo que também se baseasse em padrões? E, se os padrões 
podem ser seguidos para obter maior qualidade em outras áreas, não poderiam 
ser também seguidos para melhorar o provimento dos serviços pela TI? Siga 
este raciocínio. 


Adotar as soluções e orientações recebidas 


Outra dificuldade que normalmente mapeamos quando fazemos levan- 
tamentos das causas de insatisfação com o atendimento recebido é o fato 
de que os técnicos se queixam de que os clientes são “desobedientes” ao 
mesmo tempo em que os clientes se queixam de que os técnicos são muito 
“restritivos”. 

Nós, como técnicos, precisamos lembrar que também assumimos o papel 
de clientes em diversas outras situações da vida e também nestas ocasiões 
somos desobedientes, ou não? Veja outra analogia. Você está trafegando por 
uma estrada e de repente vê um guarda fazendo sinal para você reduzir a ve- 
locidade. Você reduz a velocidade por um tempo, vê que não tem nada logo 
a sua frente e se sente autorizado a novamente voltar a sua velocidade “de 
cruzeiro” (80km/h para alguns, 100km/h para outros, 120km/h para tantos, 
conforme a pressa e a coragem). De repente, logo depois daquela próxima 
curva, você leva o maior susto, pois está tudo parado. Você freia, desvia para 
a direita e escapa. O motorista de trás não tem a mesma sorte e fica no pre- 
juízo. A desobediência é coisa da natureza humana, que alguns insistem em 
chamar de liberdade de iniciativa. 

Quantos técnicos já não cansaram de dizer para seus clientes: “Não instale 


nenhum software na sua máquina sem autorização, pois isto poderá trazer 
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algum tipo de vírus e lhe prejudicar” E o que acontece? Por uma ou duas 
semanas o aviso é obedecido. E depois? Muita gente diz: “Me esqueci da 
recomendação.” Nem sempre dá para acreditar em esquecimento nestes ca- 
sos. Parece, mais uma vez, que algo característico da natureza humana nos 
diz que se algo que nos alertaram que podia acontecer não aconteceu por um 
bom tempo, então deve ter sido um alerta errado! E arriscamos usar nossa 
liberdade de iniciativa e voltar a fazer do nosso modo. 

Existem empresas nas quais os clientes reclamam que a TI não os atende 
de modo satisfatório e que o tempo de resolução de incidentes é muito alto. 
Dizem que a TI tem que fazer algo para melhorar. E tem mesmo. Tem que 
mostrar ao cliente que o tempo de atendimento de incidentes só é alto por- 
que existem muitos incidentes sendo causados “deliberadamente” pelo não 
atendimento das recomendações. 

Temos os casos do micro que queima, do monitor que quebra, do software 
que se perde, do arquivo que se corrompe e tantas outras coisas acontecendo 
ao mesmo tempo. Algumas destas coisas estão acontecendo por negligência, 
imperícia ou imprudência. Esta terminologia se aplica bem às causas de in- 
cidentes previsíveis e desnecessários, justamente aqueles que tomam a maior 
parte do tempo das equipes. Por culpa de quem? Pense. 

Aqui cabe mais uma analogia. Você comprou uma T'V nova. Ela tem ga- 
rantia de funcionamento por cinco anos. Aí você resolve mexer naquilo que 
não deveria mexer e queima a TV. Vai poder procurar a assistência técnica e 
exigir o conserto sem custos? E ainda brigar por um prazo de atendimento 
com urgência? Até pode. Mas talvez tenha perdido sua garantia por ter feito 
aquilo que os termos dela proibiam. 

Logo, se você é um cliente em algum processo e está na condição de 
reclamante de que o atendimento não está satisfatório, pare para pensar se 
você não é o culpado por parte disso. Se cada um fizer isso, todos os de- 
mais serão beneficiados. Você pode até não estar no grupo dos negligentes, 
imprudentes ou sem perícia, mas se você souber que seu subordinado ou 
companheiro de sala está neste grupo e não fizer nada para mudar a situa- 
ção, lamento dizer, mas você passará a também fazer parte do grupo. É o 


rincípio da “conivência”. 
P P 
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LIÇÕES APRENDIDAS: Muitas vezes a organização como um todo não está rece- 
bendo os serviços providos pela TI de modo adequado não por culpa da TI, mas 
por culpa de áreas e pessoas que “exageram” no uso dos recursos ou que não 
seguem as regras. Talvez, além de buscar modos de oferecer mais e melhores 
serviços, possamos buscar modos de consumir menos e de preservar aquilo que 
é oferecido. 


Ter visão corporativa 


Todo cliente se acha único. Já falamos na relação cliente-fornecedor. Já 
dissemos que ela é bilateral e interdependente. Mas não dissemos que ela 
é comunitária. É comunitária no sentido de que um fornecedor possui vá- 
rios clientes para atender simultaneamente e também no sentido de que um 
cliente depende de vários fornecedores para ser atendido. 

Podemos identificar neste cenário vários pontos críticos. Se olharmos 
para esta relação sob o ponto de vista do fornecedor, podemos encontrar na 
ITILº vários elementos de fundamentos que nos ajudam a estabelecer pro- 
cedimentos adequados. Vamos analisar dois deles: o catálogo de serviços e os 


acordos de nível de serviço. 


Catálogo de serviços 


Ao falar de catálogo de serviços e de clientes, o que nos salta a mente? O 
catálogo de serviços de negócio. Aquele “trem” (como diriam os mineiros) 
que parece saído das trevas e que parece um trabalho insano a ser feito e que 
vai tomar muito tempo para ser mantido. Pois é. Como é que você quer que 
seus clientes entendam que, quando eles pedem uma mudança num serviço, 
isso pode impactar outras áreas de negócio que também usam aquele serviço 


se nem você mesmo sabe? 
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Como é que você quer que seu cliente perceba que a solicitação dele não 
é assim tão crítica, pois envolve um serviço que só a área dele usa, enquanto 
um outro serviço também está parado e é usado por diversas áreas de negócio 
da organização, inclusive a do diretor dele? Vamos detalhar esse assunto nos 
próximos capítulos, mas, só para adiantar, vamos ressaltar que o catálogo de 
serviços não é um “ente” só de uso da TI. Ele é de uso também dos clientes. 
Eles devem usar este recurso para se posicionar dentro da organização com 
uma visão corporativa. 

Para que isso aconteça, muitos dos conceitos da ITIL®, tal como gestão 
de serviços, catálogo de serviços, níveis de serviço etc., devem ser conheci- 
mentos levados para o cliente. Não adianta treinar toda a TI e depois sair 
“falando grego” com os clientes. Ensine um “grego básico” para eles e a con- 
versa vai começar a fluir bem melhor. Pelo menos, vai existir uma conversa, 


e não um monólogo, sobre ITIL®, como hoje parece ainda haver. 


Acordo de Nível de Serviços 


Sempre que o assunto SLA (Service Level Agreement ou Acordo de Ní- 
vel de Serviço) é discutido dentro das organizações surgem as preocupações. 
Todos falam em SLA, cobram SLA, negociam SLA, e é SLA para cá e SLA 
para lá. Mas, na maior parte das vezes, o que se está discutindo? Prazo de 
atendimento de solicitações recebidas. Olha o prazo de novo! Já dissemos 
que “prazo” virou métrica de medição de desempenho, de qualidade, de pro- 
dutividade, de serviço bem entregue, e por aí afora. Definir um prazo para 
atender a um incidente, por exemplo, talvez represente 20% (se tanto) do que 
trata o assunto SLA, e muita gente acredita que, se, já definiu prazos, já está 
com o SLA definido. Cuidado! 

É importante destacar que o cliente é um elemento essencial na dis- 
cussão, negociação e estabelecimento do SLA. Mais uma vez não pode 
ser um assunto tratado de dentro para fora (estando dentro da TI, é cla- 
ro). O cliente precisa ser avisado (e entender) que ele é parte essencial na 


definição do SLA, mas que também ele não tem autonomia para fazer 
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isso sozinho, afinal como se chama mesmo o tal documento? Acordo! 
Se existe um acordo é porque, pelo menos, duas partes acordaram sobre 
algo. “Elementar, meu caro Watson.” Nem tanto. Vê-se por aí SLAs 
que surgem de cima para baixo (se é que me entendem) e outros que são 
absorvidos por osmose (já era assim antes, então vamos continuar a usar 


assim). Muita calma nesta hora. 


LIÇÕES APRENDIDAS: Muitas vezes, a TI procura resolver uma equação impos- 
sível: a de atender a todos com prioridade, sem restrições de recursos etc. Esta 
equação é impossível de ser resolvida porque os recursos são finitos e porque 
nem todos efetivamente possuem a mesma prioridade sob o ponto de vista da 
própria organização. Mas a TI recebendo demandas isoladas de cada área de 
negócio e não as equalizando não consegue perceber isto. É preciso tratar as 
demandas e os requisitos também com visão corporativa, equalizando-as, senão 
realmente a “conta não vai fechar”. 


Focar nos resultados 


Para finalizar as mudanças que os clientes precisam absorver (lembre-se 
de que não é uma lista completa, apenas os itens principais), vamos destacar 
a questão ligada ao “foco nos resultados”. E não estamos falando aqui dos 
resultados da TI. Estamos falando dos resultados das áreas de negócio da 
organização, ou seja, se as áreas estão produzindo os resultados que elas de- 
vem produzir, subsidiadas pelos serviços de TI que são oferecidos dentro dos 
níveis de serviço estabelecidos. Este é o papel da TI. 

Se seus clientes absorverem tal conceito, então muita coisa poderá dar 
certo. Desde a mudança do conceito de help desk para service desk, pas- 
sando pela criação e uso de um catálogo de serviço, sem deixar de passar 
pelos acordos de nível de serviço e chegando até as pesquisas de satisfação, 
quando então será decretado: a TI cumpre seu papel como viabilizadora 


da operação das áreas de negócio, e estas, por sua vez, conseguem atingir 
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seus objetivos de negócio fazendo a organização cumprir também seus 
objetivos corporativos. Se isso acontecer, teremos certeza de ter atingido 
nosso objetivo. 

Mas, para chegar lá, primeiro cada um precisa saber qual é o papel da sua 
área de negócio, quais são seus objetivos, quais são os recursos e serviços que 
irá necessitar alocar para cumprir estes objetivos, e assim por diante. O que 
isso significa? Que deve existir um conceito de governança ou gestão corpo- 
rativa estabelecido e operante. Será muito difícil implantar um processo de 
Gestão de Serviços de TI (com fundamentos da ITIL®) se a visão de gestão 
não estiver clara para todos, principalmente se o espírito de colaboração entre 
áreas, de busca de resultados por área e corporativos não for uma prática diá- 
ria. Existem muitas empresas nas quais, apesar desta visão já existir, muitas 
pessoas (usuárias da TI) estão mais preocupadas com os seus desempenhos 
pessoais, objetivos e resultados do que com a visão corporativa. E é claro que 
isso gera distorções. 

Enquanto eu, como cliente, estiver preocupado com o meu resultado pes- 
soal, estarei defendendo que o meu chamado deve ser atendido na frente do 
chamado dos demais. Não porque eu tenha um processo crítico na minha 
área de negócio e, portanto, seja um “usuário VIP”, mas porque “eu sou o 
cara”. Não se trata de gerar resultados para o negócio, mas de gerar projeção 
própria. 

Esta é uma distorção que não tem nada a ver com os fundamentos da 
ITILº. Até temos na ITIL® a apresentação do conceito de um usuário VIP, 
mas há de se compreender que este não é um perfil pessoal, mas um atributo 
de uma pessoa ligada a um processo crítico. Talvez, na próxima versão da 
ITILº, tenhamos o conceito de processos VIP, em vez de pessoas VIP. A 
visão de pessoas VIP parece ser uma herança dos “velhos tempos”. 

Precisamos conseguir demonstrar num cenário como este que interesses 
pessoais são incompatíveis com os fundamentos básicos da gestão de serviços 
de TI. Toda a teoria da gestão de serviços de TI está voltada para produzir 
resultados para as áreas de negócio e para a corporação, não para as pessoas. 

Isto realça mais um aspecto importante. A preparação da organiza- 


ção para receber a gestão de serviços de TI é uma tarefa interdisciplinar e 
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interdepartamental. Não é um esforço isolado da TI. Não pode ser um proje- 
to da TI. Tem que ser um projeto corporativo que ou será apoiado por todos 


ou tenderá ao fracasso. 


LIÇÕES APRENDIDAS: Não há como viabilizarmos a implantação da gestão de ser- 
viços de TI, nem sequer pensar em ITIL®, se não formos capazes de estabelecer 
o conceito de que os serviços existem e serão disponibilizados para atingir resul- 
tados das áreas funcionais, e não para atender a demandas pessoais. Enquanto 
o lado pessoal estiver acima do lado institucional, continuaremos a ter um eterno 


help desk, e nunca um service desk. 


ONDE A TI SE POSICIONA NA ORGANIZAÇÃO? 


Esta é a primeira questão que deve ser discutida não com a TI, mas com 
seus clientes e com a organização. Ainda existem aqueles que não deixaram 
de ver a área de informática como uma área de apoio. Não que não seja. 
Realmente o papel da informática é ser a facilitadora para as operações das 
demais áreas, mas imaginar que esta finalidade pode ser confundida como 
simples função de apoio é uma visão equivocada. Primeiro, porque uma 
área de apoio acabaria por criar uma dependência muito forte com as áreas 
apoiadas. No passado, e ainda em algumas empresas, a informática estava 
vinculada ao departamento financeiro, pois historicamente todo o proces- 
samento de dados estava muito ligado a questões financeiras e contábeis. 
Porém, os tempos mudaram. Hoje, a informática não poderia ser vinculada 
a uma ou outra área, principalmente se desejasse ser uma provedora de ser- 
viços de TI. Ser uma provedora de serviços, e não só uma fornecedora de 
tecnologia da informação, lhe dá um patamar de igualdade com as demais 
áreas provedoras de serviços de RH, serviços financeiros, serviços opera- 
cionais etc. 

Para aquelas empresas que já adotaram princípios de gestão baseados em 
governança corporativa fica claro que a TI é uma área com autonomia, com 


objetivos próprios, com recursos e estratégias específicas, mesmo sendo uma 
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atividade-meio (se não considerarmos as empresas nas quais a TI é a ativida- 
de-fim, é claro). Mas, como nem todas as organizações têm esta visão clara, 
é necessário, então, que nós da TI consigamos expor para nossos clientes a 
visão de que o relacionamento entre as demais áreas e a TI se dá em grau de 
igualdade, sem hierarquias. 

Não significa que nosso esforço para implantar a Gestão de Serviços de 
TI vá depender de haver ou não uma hierarquia entre a ela e outras áreas, 
mas a valorização do processo de Gestão de Serviços de TI será bastante 


beneficiada se estivermos lado a lado. 


Perfil tradicional Perfil GSTI 


Provedora de Provedora de 


Tecnologia da Serviços de 
Informação Informação 


Este assunto traz à discussão outra questão importante: os clientes pre- 
cisam ver a TI não como área provedora de tecnologia da informação, mas 
como área provedora de serviços de informação. Já há algum tempo sem- 
pre comentávamos em nossos treinamentos que em breve as áreas de TI 
deixariam de ser chamadas de TI e passariam a ser chamadas de áreas de 
SI (Serviços de Informação). Recentemente, ao comentarmos isso, encon- 
tramos um caso prático no qual esse panorama já havia acontecido em uma 
empresa. À empresa em que o aluno trabalhava (uma multinacional do 
setor industrial) já adotava este termo fora do Brasil e agora também aqui 
passava a denominar a área de “Departamento de Serviços de Informação”. 
Logo, ele não era mais um coordenador de TI, e sim um coordenador de 
SI. Os tempos mudaram. 

Esta mudança reforça perante os clientes o papel da TI (vamos continuar 
o termo TI para não causar futuras confusões) como uma provedora de servi- 
ços, ou como uma área que tem um processo de gestão daquilo que provê, ou 
até como uma área com gestão profissionalizada focada em prover serviços 
aos clientes. Novos tempos. 
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LIÇÕES APRENDIDAS: O sucesso da implantação da gestão de serviços de TI não 
é uma questão técnica. Depende primeiramente de mudanças organizacionais. 
Sem receptividade ou patrocínio corporativo, todo o esforço técnico pode ser 
irrelevante. A gestão de serviços de TI precisa ter o seu lado “gestão” reforçado. 
A TI precisa ser vista como área de SI. 


COMO ASSEGURAR O APOIO DA ORGANIZAÇÃO 
A NOSSAS INICIATIVAS? 


Os clientes precisam ver a TI como um novo papel dentro da organização, 
mas esta visão não deve ser somente institucional. Ela precisa ser também uma 
visão pessoal repassada por cada diretor de cada área de negócio a todos os seus 
subordinados, e assim por diante, até os níveis operacionais da pirâmide. 

Lembre-se de que, do ponto de vista prático, o relacionamento mais 
complexo a ser mantido pela TI será com os usuários dos serviços. Have- 
rá um relacionamento entre cliente e TI nos momentos de definições de 
níveis de serviço, de levantamentos de demandas etc. Porém, no instante 
do tratamento de incidentes, de atendimentos a requisições, de avaliação 
de mudanças, serão os usuários dos serviços que estarão presentes nos 
processos. Isto implica que cada chefia deva assegurar o comprometi- 
mento de cada um de seus subordinados com as iniciativas e processos 
executados pela TI. 

Isso parece, inicialmente, um desafio difícil de ser superado, mas se tra- 
tado de modo adequado pode sim ser feito. O que precisa ser feito é, mais 
uma vez, transferir o foco para os resultados e não para os meios. Não se trata 
de cada gerente em cada área solicitar o apoio da TI a seus funcionários. O 
que deve ser obtido é o apoio à ideia de que cada área existe para produzir 
resultados e que todas as iniciativas que contribuírem para isto devem ser 
apoiadas sejam elas vindas da TI ou de qualquer outra área. Não se trata só 
de discutir o que será feito, mas, antes de tudo, de discutir se desejamos ou 


não os resultados que serão produzidos! 
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PARA QUE DEVE SER FEITO? 


RESULTADO 


É certo que este discurso de busca de resultados pode ter maior ou menor 
aderência em diferentes perfis de empresas, com diferentes tipos de colabo- 
radores. Em mercados altamente competitivos, com certeza, encontraremos 
empresas dispostas a buscar resultados para suas áreas de negócio custe o que 
custar. Também em mercados de empresas altamente estruturadas não será 
difícil usar o discurso da busca de resultados. Porém, você deve ser capaz de 
imaginar segmentos em que a preocupação com resultados possa não ser assim 
tão essencial. Vou deixar você livre para imaginar estes cenários e tentar iden- 
tificar empresas em que isto possa ocorrer. Tenho certeza de que você conse- 
guirá encontrar exemplos. Nestas empresas, então, tentar implantar a gestão 
de serviços de TI e conseguir apoio das outras áreas de negócio será um desafio 


a ser superado com outras estratégias. Mais à frente falaremos sobre isso. 


LIÇÕES APRENDIDAS: Ofereça benefícios para obter apoio e baseie seus argu- 
mentos em resultados que as áreas poderão obter. Comece com os níveis hie- 
rárquicos superiores, mas não utilize a hierarquia para impor regras aos níveis 
inferiores. Utilize-os para conseguir apoio. Se os níveis superiores não estiverem 
engajados, os níveis inferiores terão maior resistência em se engajar. 


SERÁ FÁCIL CONSEGUIR ESTAS MUDANÇAS NA ORGANIZAÇÃO? 


Estamos finalizando este primeiro capítulo, e não poderia deixar de falar 
sobre o ponto de partida do sucesso da implantação da Gestão de Serviços 
de TI através do uso das melhores práticas da ITILº: a preparação da orga- 


nização para receber este novo paradigma de atuação. 
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Não são questões que possam ser resolvidas tecnicamente, o que pode 
tornar tudo mais complicado, pois muitos dos envolvidos com a ITIL®, 
que vieram dos cursos de fundamentos, têm perfil técnico. Pudemos per- 
ceber que muitas questões aqui discutidas envolvem relacionamentos, 
busca de apoio, estratégias de convencimento, engajamento, identifica- 
ção de resistências e modos de contorná-las, reconhecimento de compor- 
tamentos, entre outros. Todas estas questões estão ligadas aos aspectos 
humanos e sociais e isso deve criar uma dificuldade adicional, mas não 
deve ser motivo para se descartar nada do que foi abordado aqui. Não é 
uma questão de opção entre fazer ou não fazer. Terá que ser feito mais 
cedo ou mais tarde através do processo de melhoria continuada, então 
é melhor que seja o mais cedo possível, pois aí tudo tomará o seu rumo 
certo o mais breve possível. 

Estes não são temas tratados diretamente nos cursos de fundamentos de 
ITILº, mas, com certeza, são temas que não deveriam deixar de ser conside- 
rados em qualquer planejamento de implantação da gestão de serviços de TI. 
Considere a adoção deles na sua próxima abordagem. À experiência mostra 
que podem, sim, ser um diferencial em seus projetos. Lembre-se sempre da 
palavra “gestão”, que está presente no termo “gestão de serviços de TT”. Se 
você ainda não tem um perfil desenvolvido para ser um gestor, procure en- 
tão melhorar neste aspecto, pois ele será constantemente exigido daqui para 
frente. 

E por ora, uma última analogia (neste capítulo, é claro). Quem já presen- 
ciou a implantação de um processo de gestão da qualidade em uma empresa 
pode talvez aceitar muito bem todas as ideias aqui expostas. Imagine que sua 
empresa optou por usar a ISO-9001 como guia para seu programa de quali- 
dade. Ela preparou uma equipe de auditores internos, contou com auditores 
externos, buscou a certificação, certificou-se. 

Quem acompanha o que acontece realmente num plano desses deve co- 
nhecer uma etapa muito importante: a disseminação da cultura da qualidade 
na empresa. Todos, mas todos mesmo, desde o presidente até o estagiá- 
rio do almoxarifado, devem ser “catequizados” sobre qualidade. Mesmo que 


haja uma área específica de gestão da qualidade que administre todo este 
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processo, ou que um escopo seja delimitado, todos na empresa precisarão 
entender por que as coisas terão que ser feitas de um novo modo. Precisam 
se convencer de que não basta um ou outro dentro da organização “comprar 
a ideia”. Qualquer pessoa que não compre a ideia poderá fazer com que o 
esforço de muitos se perca. 

A mudança imposta pela implantação da gestão da qualidade numa em- 
presa é tão abrangente quanto a mudança imposta pela implantação da ges- 
tão de serviços de TI, pois mesmo sendo os dois trabalhos coordenados e 
conduzidos por áreas específicas, eles influenciarão toda a corporação. Este 
é o espírito de preparação da organização que devemos buscar quando pen- 
sarmos em dar o primeiro passo na implantação de nossa gestão de serviços 
de TI. Mais do que um primeiro passo, eu diria que este é um pré-requisito 
indispensável. 


LIÇÕES APRENDIDAS: Ao se falar em gestão, devemos sempre lembrar que esta- 
mos envolvendo aspectos pessoais, sociais, administrativos e de relacionamento 
entre pessoas. Não aposte só em seus conhecimentos técnicos de ITIL® na hora 
de iniciar a implantação da gestão de serviços de TI, principalmente se todo o 
conhecimento técnico que você tem está concentrado nos fundamentos da ITILO. 
Aperfeiçoe-se ou busque apoio externo para obter estas competências. 
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Preparar a empresa para a GSTI 
Preparar a TI para a GSTI 
Construir um CMDB 
Construir um Catálogo de Serviços 


Construir Acordos de Nível de Serviço 


Construir uma Base de Conhecimento 


Implantar processos operacionais 


A o fazer essa pergunta a primeira resposta que normalmente recebemos 
é: fazendo um treinamento de ITIL®. Correto. Este é um bom começo 
realmente. Não há como querer fazer a implantação de uma gestão de servi- 
ços sem conhecer a ITIL® ou coisa parecida. Sim, existe coisa parecida. Você 
já ouviu falar do MOF (Microsoft Operations Framework)? Pois dê uma 
lida sobre ele e veja que ideias interessantes. Não poderiam ser ideias ruins, 
pois o objetivo dele também é servir de base para a gestão de serviços de TI. 
Logo, qualquer curso ou base teórica que você procure e que tenha o assunto 
gestão de serviços de TI como tema é um bom começo. 

Mas para que o curso vai servir? Para me deixar pronto para implantar a 
gestão de serviços? Com certeza não. Esta primeira fase é o que chamamos 
de iniciação. Parafraseando as fases dos estágios de Nolan, criados em 1973 
e depois revisados em 1979 e que eram focados na implantação de sistemas 
de informação (que podemos agora tentar ver como serviços), criaremos os 
estágios da implantação da gestão de serviços na organização. 

Esta não é a mesma abordagem usada para definição dos níveis de ma- 
turidade de gestão de serviços apresentada nos livros oficiais da TTILº. 
O que veremos são só estágios da implantação. Depois de implantada, a 
GSTI poderá evoluir em maturidade e aí então a visão de maturidade pode 
ser usada. Esta é uma visão que desenvolvi e que estou repassando para sua 
avaliação. 
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QUAIS SÃO OS ESTÁGIOS DA IMPLANTAÇÃO DA GSTI? 


Vamos estabelecer que os estágios também são seis: início, contágio, con- 
trole, integração, administração, maturidade. Estes eram os nomes originais 
usados por Nolan e que, em respeito e crédito ao autor, vamos manter adap- 


tando o contexto. 


CONTROLE 


INTEGRAÇÃO 


ADMINISTRAÇÃO 


MATURIDADE 


Início 


Neste estágio a gestão de serviços de TI dentro da organização é uma 
iniciativa isolada de um grupo de pessoas (talvez você sozinho) e precisa ser 
disseminada para outras pessoas e áreas de modo a gerar um convencimen- 
to de que o caminho é este. É neste estágio que defendemos que um bom 
treinamento de ITIL Foundationsº é essencial para um grupo de influencia- 
dores. As pessoas precisam criar massa crítica recebendo e absorvendo no- 
vos conceitos. Precisam se convencer dos benefícios que podem ser gerados. 


Precisam se convencer da viabilidade da iniciativa. 


Contágio 


Na fase do contágio começa a haver uma disseminação de ideias para 


outras pessoas fora do grupo que originou a iniciativa. Esta disseminação 
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pode ser feita através de seminários internos, repasse de materiais para leitu- 
ra (já contextualizados para o ambiente da sua empresa). Nesta etapa é vital 
“contagiarmos” também a organização. Todos os aspectos que trabalhamos 
no Capítulo 1, mostrando que o cliente precisa mudar o seu modo de vista 
com relação à TI, chamando-a inclusive de SI (Serviços de Informação), 
deveriam ser praticados nesta fase. E por que agora? Porque se não conse- 
guirmos “contagiar” a organização neste momento, mais tarde será cada vez 
mais difícil. Precisamos inclusive descobrir se a organização não está imune 


ao contágio e talvez estejamos em “rota de colisão”. 


Controle 


Tendo havido um contágio suficiente (pois talvez o contágio desejado 
nunca seja obtido na escala imaginada), podemos partir para a fase de esta- 
belecimento de mecanismos de controle. Estes mecanismos serão a base para 
execução de uma gestão de serviços de TI profissional. Algo que não fuja de 
nosso controle. Algo que não pareça estar sendo realizado intuitivamente ou 
ao acaso. Não se trata de criar controles, mas de criar artefatos que levem ao 
controle. Só para exemplificar, podemos citar aqui a criação de um catálogo 
de serviços, de acordos de nível de serviço, de um banco de dados de gestão 
de configuração, de um sistema de gestão de conhecimento sobre o serviço e 
por aí afora. Por isso, nos próximos capítulos, vamos nos aprofundar nestes 


temas. Estes artefatos são as bases do controle da gestão de serviços de TI. 


Integração 


Nesta fase, já podemos passar à definição de processos que integrem 
o uso dos mecanismos de controle criados na fase anterior e que permi- 
tam que possamos fazer, fazer bem, no tempo certo, sempre e de modo 
integrado. Aqui, numa visão prática, estamos falando, por exemplo, de 


definir um processo de gestão de incidentes que integre informações do 
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catálogo de serviços com os requisitos dos acordos de níveis de serviço, com 
os dados de configuração dos serviços, com os dados sobre o conhecimento 
dos serviços para então permitir que, na ocorrência eventual de incidentes, 
os serviços sejam restabelecidos no menor tempo possível, respeitando-se 
suas prioridades e características e também as das áreas que os demandam. 
Muitas empresas dizem que vão começar a implantação da TTILº (sic) pelo 
processo de gestão de incidentes. Usando os ciclos de Nolan adaptados à 
ITILº dá para se perceber que alguém que queira começar tudo pela in- 
tegração pulou a etapa de controle, essencial para produzir os elementos 
básicos que a gestão de incidentes precisa usar. Vamos discutir isto nos 


próximos capítulos. 


Administração 


Tendo-se implantado alguns processos principais (será que existe o con- 
ceito de processo principal na ITIL®?), podemos partir então para a fase de 
administração de resultados. Nesta fase, deveremos, a partir das métricas 
estabelecidas e das iniciativas implementadas, verificar continuamente se es- 
tamos alinhados com os objetivos da organização ou, em outras palavras, 
verificar se nosso plano deu certo, ou o quanto deu certo. Não quer dizer que 
esta fase só vai se iniciar depois de totalmente terminada a fase da integração. 
Como o termo integração já sugere, teremos necessariamente um processo 
sendo integrado antes do outro, e cada um, por sua vez, se integrando aos 
já existentes. Portanto, ao ter um processo implantado, já se inicia a fase de 
administração para este processo, que depois de integrado aos demais passa 


a ser administrado, e assim por diante. 


Maturidade 


Por último, entramos na fase da maturidade da gestão de serviços de TI, 
na qual as iniciativas de melhoria contínua dos processos são agregadas. 
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Também esta fase não requer que a fase anterior seja totalmente cumprida 
para ter seu início decretado. Para cada processo criado e administrado, po- 
deremos já ter o início da fase de maturidade desde que os resultados por ele 
produzidos sejam passíveis de melhorias (e quase sempre são). Assim sendo, 
tão logo as ações de melhoria se mostrem necessárias e sejam executadas, 
estará iniciada a fase de maturidade para aquele processo. 

Fica claro que as fases de início e contágio são importantes, mas que tam- 
bém são igualmente importantes as fases de controle, integração, adminis- 
tração e maturidade. Ou seja, todas merecem atenção da TI para as mudan- 
ças que exigirão. Com certeza, quanto mais se evolui dentro de cada fase, 
mais complexa se torna a manipulação e interligação dos conceitos que se 


incorporam gradualmente. 


LIÇÕES APRENDIDAS: A maturidade na gestão de serviços de TI dependerá de 
diversas iniciativas e esforços em cada uma das fases anteriores pela qual a TI 
passar. Não espere resultados da fase de maturidade se você ainda está na fase 
de contágio. Não comece pelo fim. 


QUAL A PRIMEIRA MUDANÇA NECESSÁRIA NA TI? 


A primeira mudança a ser feita pela TI, com certeza, não deve ser a 
troca da placa na porta da sala da equipe de suporte de “help desk” para 
“service desk”. Realmente, talvez as pessoas não façam logo esta mudança, 
mas com certeza a primeira coisa que fazem é começar a não falar mais em 
“help desk” e a usar o termo “service desk”, ou então param de falar em 
“chamados” e começam a falar em “incidentes”. Parece que ao falar em ser- 


vice desk e incidentes realmente se sentem como se tivessem “implantado 


a ITILº” (sic). 
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Setor de 
Help Desk 


Setor de 
Service Desk 


Mas, então, de que mudança estamos falando? De uma mudança que 
também envolve o termo “service”, mas não o termo “service desk”, e sim 
o “service” sozinho. O conceito de serviço de TI precisa ser incorporado, 
entendido, praticado e disseminado dentro da TI. Uma área não poderia 
se chamar service desk enquanto não planejasse, construísse, entregasse e 
monitorasse serviços, negociasse níveis de serviço, tratasse incidentes de ser- 
viços, gerenciasse mudanças em serviços e por aí afora. 

Por mais estranho que isso pareça, ainda vemos empresas que possuem um 
service desk tratando as solicitações que recebem não com foco nos serviços 
que elas representam, mas nos equipamentos e softwares que eles envolvem. 
E aí, então, mesmo tendo uma área chamada de service desk, o atendente 
que lá trabalha vai registrar um incidente, mas não vai perguntar qual é o 
serviço afetado, e sim: “Onde tá dando erro? É no Outlook?” (sic). E do serviço 
de correio eletrônico ninguém lembrou! Nem o usuário nem o atendente 
fazem qualquer menção ao serviço indisponível, mas sim aos componentes 
de tecnologia que o compõem. Um ambiente destes continua a ser um help 
desk disfarçado de service desk. 

O mesmo acontece logo depois que o incidente é registrado. Em vez de 
se buscar uma solução de contorno que restabeleça o serviço, o técnico vai 
gastar um tempão procurando identificar o que é que tem de errado e como 
é que ele pode fazer para consertar. Fomos, por décadas, treinados para pro- 
curar defeitos e consertá-los. Não fomos treinados para dar soluções de con- 
torno. Oferecer uma solução de contorno para muitos parece uma declaração 
de incompetência, ou uma tentativa de se livrar do chamado, mas deveria ser 
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justamente o contrário. Buscar uma solução de contorno deveria ser um mé- 
rito, pois seria a maneira mais rápida de restabelecer o serviço para o usuário. 
Logo, será muito provável que os antigos vícios acabem por superar as novas 
boas intenções e logo teremos um service desk funcionando como um velho 
e bom help desk. 

Se nem o cliente nem a equipe de TI absorverem o conceito de serviço, 
então falar de service desk, de gestão de serviços, de nível de serviço e tantos 
outros termos ligados ao serviço será somente uma mudança de linguajar. E 
mudar os termos usados para designar as coisas não vai efetivamente mudar 


algo que traga resultados para a organização. 


LIÇÕES APRENDIDAS: Não adianta começar somente trocando a terminologia 
usada no ambiente. A mudança tem que ser conceitual e comportamental. 
Se um novo modelo de atendimento e suporte não for implantado continua- 
remos a colher os mesmos resultados que hoje já temos. Se você deseja 
mudanças nos resultados, então precisa implantar mudanças no modo de 
fazer as coisas. 


Mas então onde está o erro? Será que os cursos não estão ensinando o 
que é um serviço? Ou seriam os livros os culpados? Apostilas na web? Pa- 
lestras? Conversas com amigos? Talvez um pouco de tudo isso. Lembra-se 
dos estágios de Nolan? Aquela fase em que ocorria o contágio? Bem, nesta 
fase aqueles que absorveram algum conteúdo num curso de fundamentos de 
ITILº acabam por se motivar e querer repassar os conceitos adiante. E aí 
pode ocorrer uma transmissão e retransmissão de conceitos de um para outro 
até que lá na ponta algo chegue distorcido. É muito frequente ver por aí mui- 
tas pessoas que só fizeram a certificação de ITIL Foundationsº ministrando 
cursos de ITIL Foundations?. É o caso de alguém que só tem os conceitos 
fundamentais tentando repassar exemplos, conceitos e argumentos. Há um 
risco. Não que não possa, às vezes, funcionar, mas seria mais apropriado 
buscar alguém com muito mais conhecimento ou fontes mais confiáveis de 


informação. 
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ATENÇÃO: Cursos não qualificados de ITIL Foundations® ou materiais de auto- 
estudo sem origem confiável podem até ser prejudiciais para as organizações 
que querem implantar a gestão de serviços de TI. Isso porque se o material 
não for realmente de qualidade podemos estar começando todo um processo 
baseado em meias verdades. Deveriamos confiar mais em cursos e materiais 
produzidos por fontes confiáveis e por especialistas certificados nos assuntos 
sobre os quais escrevem e falam: pessoas com maior bagagem teórica e prática 
de gestão de serviços de TI baseada na ITIL®. Verifique suas fontes de infor- 
mação. 


Tanto na fase de início como na fase de contágio, mesmo que existam 
pessoas liderando o movimento de implantação da gestão de serviços de TI 
que já possuam os conceitos básicos, é importante buscar apoio qualificado 
para a disseminação, nem que seja pontual. Esta fase de contágio é tão im- 
portante para o sucesso do projeto que não deveríamos poupar esforços e 
investimentos para assegurar o sucesso, pois é nela que temos que ser efetivos 
no convencimento de mais pessoas na corporação. 

Existem projetos nos quais na fase de contágio a empresa opta por mon- 
tar uma estratégia de “multiplicadores internos” para poupar recursos, o 
que faz com que materiais e cursos internos sejam produzidos e repassados. 
Mas o primeiro erro que cometem é produzir materiais e palestras similares 
a um curso de ITIL Foundationsº, portanto técnicos demais, e tentar usar 
estes recursos para convencer pessoas de fora da TI de que a iniciativa seria 
boa para eles. O resultado é que muitos dos usuários externos que partici- 
pam destes treinamentos têm uma única impressão ao final: “Este negócio 
é muito complicado. Não entendi nada.” Imagine você falar de ciclo de 
vida de serviço, de diferença entre incidente e problema, de processo de 
gestão de mudança e liberação para um gerente de RH... Não pode mesmo 
dar certo! 

A analogia da construção de uma casa pode nos dar uma visão clara 
do que estamos falando. Não adianta você economizar na fase de projeto 


e depois querer contratar a melhor construtora da cidade para executar a 
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construção. Um projeto que seja mal concebido acabará mal mesmo com a 
melhor construtora da cidade, nem que seja em termos de custos e prazos. 
Boas sementes não garantem bons frutos, mas devem ter maior probabili- 


dade de gerá-los. Já as sementes ruins raramente produzirão bons frutos. 


LIÇÕES APRENDIDAS: Busque material e orientação qualificada desde a fase de 
início e contágio. Invista numa fundamentação de qualidade. Desconfie daqueles 
que lhe prometam novos resultados sem algum tipo de esforço adicional. 


ORIENTAR A TI PARA SERVIÇOS SERÁ SUFICIENTE? 


Orientar a TI para serviços será necessário, mas não suficiente. Existem 
ainda outras iniciativas a serem tomadas. Imagine que todos os participantes 
do processo já entenderam que agora a TI fornece serviços e não mais tecno- 
logia. Imagine que o cliente já consegue expor suas necessidades de serviço e 
não somente pedidos de equipamentos e softwares. O que mais fica faltando, 
então? Artefatos de apoio aos processos. 

O processo de gestão de serviços de TI, para funcionar adequadamente, 
se baseia em uma série de artefatos ou elementos de base que são essenciais. 
Diria até que são vitais. E de onde vem esta visão? Da observação de outros 
processos de gestão ou de analogias. Vamos imaginar, por exemplo, algumas 
outras áreas de gestão tais como a de RH, a financeira e a de materiais. Como 
você iniciaria um processo de gestão de RH? Talvez criando um cadastro de 
funcionários, muitos responderiam. E como iniciaria um processo de gestão 
financeira? Pela criação de um plano de contas, diriam outros. E um siste- 
ma de gestão de materiais começaria como? Com um cadastro de itens de 
material, pensariam outros. E estão certos! Isso mostra que a criação de um 
cadastro dos principais itens que deverão ser administrados no processo deve 
ser um bom começo. O mesmo vale para a gestão de serviços de TI. Teremos 
que criar cadastros, procedimentos de manutenção, de manipulação e de di- 


vulgação, você concorda? 
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Cadastro de 
itens de mat. 


Plano de 
contas 


Cadastro de 


funcionários 


Gestão Gestão Gestão de Gestão 
de RH financeira materiais de TI 
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E com este argumento que podemos abordar a questão de que, por 
exemplo, a gestão de configuração, a criação de um CMDB (Configuration 
Management Database ou Banco de Dados de Gestão de Configuração), 
a definição de procedimentos de manutenção e publicação destes dados é 
essencial. Assim como o catálogo de serviços de negócio, o catálogo de servi- 
ços técnicos, os acordos de nível de serviço, os acordos de nível operacional, 
as bases de conhecimento e assim por diante. Muita coisa que nos cursos de 
fundamentos parecem “melhores práticas”, “melhorias” ou “aperfeiçoamen- 
tos” passam então a parecer pré-requisitos, itens essenciais. 

Portanto, além de criar novas culturas, novos conceitos e novas termi- 
nologias, precisamos também criar elementos concretos que serão aplicados 
no dia a dia para permitir que os demais processos operem corretamente. 
Alguém já se perguntou como é que uma empresa escolhe começar a implan- 
tação da gestão de serviços de TI pelo processo de gestão de incidentes? Seria 
pela facilidade de compreender o processo? Seria porque os incidentes são os 
elementos que mais trazem impacto para a organização? Seria porque este é 
um processo intimamente ligado ao service desk? Não importa. 

Muitas empresas optam por começar pelo processo de gestão de incidentes, 
mas não pensam em questões do tipo: Como é que vamos gerenciar incidentes 
de serviços se não temos um catálogo de serviços? E como vamos conhecer os 
itens a suportar se não temos um CMDB? E como vamos estabelecer métricas 
de resolução de incidentes se não temos ANSs (Acordo de Nível de Serviço)? 
Então, como vamos começar com os incidentes se não temos os itens essen- 
ciais? Porém muito começam, mesmo sem estes itens essenciais, ou tendo os 


itens essenciais, mas sem ter processos que os mantenham. 
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E referente a um SERVIÇO do CATALOGO 


E gerado por uma falha em um ITEM DE CONFIGURAÇÃO 


É resolvido dentro de um ACORDO DE NÍVEL DE SERVIÇO 


INCIDENTE 


LIÇÕES APRENDIDAS: Sem os artefatos de apoio que a ITIL® sugere será muito 
difícil viabilizar a mudança de comportamentos e de processos. Poderemos falar 
em, discutir e nos referenciar à ITIL®, mas não estaremos praticando o que a 
ITIL® sugere. Precisamos de elementos concretos que mostrem que realmente 
as melhores práticas estão sendo adotadas. 


O QUE A TI DESEJA OBTER, AFINAL? 


Partindo do princípio de que vamos investir num bom início e contágio, 
e de que vamos criar os elementos essenciais, resta a pergunta: “O que que- 
remos, afinal?” Você já deve saber a resposta a esta altura do livro. O que 
obteremos é um cliente mais satisfeito com os serviços oferecidos. Só que a 
maioria das pessoas, quando perguntada sobre a mesma coisa, pode rapida- 
mente pensar em resultados internos para a TI. Vamos abordar alguns deles 


e ver algumas particularidades de como tratá-los. 
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O que queremos? Um novo processo de atendimento 


O principal objetivo de se adotar a gestão de serviços de TI parece ser, 
para muitos, estabelecer um novo processo de atendimento que permita cor- 
rigir as deficiências do processo atual ou simplesmente melhorá-lo. Só que 
quando realmente começamos a falar em mudar as coisas, muitas dessas pes- 
soas reagem com argumentos tais como: “Aqui, isto não vai dar certo”, “as 
pessoas são muito resistentes a mudanças”, “não poderíamos manter este ou 
aquele modo de trabalho para evitar conflitos?” e por aí afora. Isso significa 
que a mudança para muitos pode até ser feita, desde que sejam pequena, que 
os costumes sejam mantidos e que poucos sejam impactados, e principal- 
mente que elas próprias não sejam muito afetadas. 

Ora, sabemos que mudanças geram impactos, exigem esforço, estão sujei- 
tas a riscos e geram custos. Por outro lado, podem produzir benefícios, redu- 
zir esforços futuros, minimizar riscos conhecidos e custos futuros. Mudanças 
são investimentos e, como todo investimento, requerem avaliação de riscos e 
retornos. Aqui vale a analogia com o mercado financeiro. Se você não quer 
correr muitos riscos, também não vai ter grandes ganhos. Às vezes, terá que 
ser conservador em alguns investimentos, mas em algum instante terá que 
ser arrojado em outros para que, na média, os ganhos sejam significativos. 
Quem não apostar não terá chances de ganhar. A análise de riscos é impor- 
tante, mas não deve inibir totalmente as apostas, principalmente se você tiver 


a orientação de alguém que opere neste mercado. 


LIÇÕES APRENDIDAS: O desejo de mudanças deve ser acompanhado de ações que 
levem a mudanças. Se desejamos resultados diferentes, precisamos de processos 
diferentes, de conceitos inovadores, de mudanças. Se continuarmos a fazer tudo do 
mesmo modo que já fazemos, continuaremos a obter os mesmos resultados. 


O que queremos? Maior produtividade no atendimento 


Outro objetivo normalmente citado quando se faz a implantação da ges- 


tão de serviços de TI é a busca de maior produtividade das equipes através de 
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novos processos, usos de novos recursos etc. Mas por que aumentar a produ- 
tividade? Muitos argumentam que é porque existem chamados demais nas 
filas para serem atendidos. Parece até fazer sentido. Se você tem chamados 
demais para resolver e não pode aumentar sua equipe, então você precisa de 
aumento de produtividade da equipe. Este raciocínio está certo, dentro de 
certas condições, mas normalmente é aplicado de modo indevido. 

Imagine uma central de atendimentos que tem excesso de incidentes a 
resolver. À busca de maior produtividade no curto prazo pode ser uma estra- 
tégia para reduzir as filas e a retenção de chamados. Porém, no médio e lon- 
go prazos, esta estratégia não irá se provar adequada, pois a questão correta 
não deveria ser encontrar um modo de atender mais, mas de atender menos 
(recebendo menos incidentes, é claro). Perceba que, novamente, este obje- 
tivo está se concentrando só numa visão interna da TI. Se a TI tem muitas 
tarefas a cumprir, então ela irá buscar um meio de cumpri-las com rapidez 
para que não existam reclamações. Porém, se formos analisar o objetivo com 
uma visão externa à TI iremos descobrir que o que o cliente deseja é que as 
coisas não apresentem falhas, e não que sejam corrigidas rapidamente. 

Para provar que esse realmente deveria ser um ponto a reavaliar nos nos- 
sos objetivos, deveríamos observar o mundo real e verificar quantos exemplos 
temos na vida prática que nos mostram a mesma perspectiva. Procure se 
lembrar da sua experiência mais recente com uma empresa de telefonia (vou 
usar o exemplo só porque este é o tipo de empresa que mais apresenta recla- 
mações de atendimento, segundo as pesquisas). 

Você adquiriu um serviço (nosso foco é a gestão de serviços) de internet 
móvel para utilizar em suas viagens e deslocamentos. O que você espera en- 
tão? Poder usar o serviço contratado. Não lhe interessa como ele é operado, 
como foi configurado, como foi implantado e, em princípio, nem como é o 
suporte dele quando ele apresentar problemas. 

Você já viu alguém indo a uma loja de venda de pacotes de serviço de 
internet móvel e perguntando em primeiro lugar se o serviço de atendimen- 
to em casos de falhas é bom? Se eles são rápidos para registrar e resolver 
incidentes? Esperamos que a primeira preocupação da companhia telefôni- 


ca ao lançar um serviço seja investir tempo e dinheiro para assegurar a boa 
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qualidade do serviço. Esperamos que ele simplesmente funcione e funcione 
sempre. Se investimentos neste sentido forem feitos, a busca de maior pro- 
dutividade no atendimento a reclamações não precisará ser uma prioridade 
(apesar de poder existir como objetivo secundário). 


LIÇÕES APRENDIDAS: Maior produtividade deve ser associada a um programa 
de qualidade. Fazer mais não é necessariamente um sinônimo de produtividade. 
É necessário produzir mais mantendo a qualidade. 


O que queremos? Maior controle através de métricas 


A busca de controle sobre o processo de atendimento também é, frequen- 
temente, citado como um dos objetivos em muitos projetos de implantação 
da GSTI. Os patrocinadores do projeto pensam que, se hoje existem filas, 
pendências, atividades em excesso, nível de satisfação baixo, então eles de- 
vem controlar de modo mais preciso este cenário. Como a ITILº usa uma 
abordagem constantemente baseada em indicadores, este tema soa como 
música aos ouvidos dos gestores de TI. Parece ser a oportunidade de defini- 
tivamente ter controle sobre o que acontece e, principalmente, sobre o que 
não acontece. 

Aqui surge outra distorção de objetivos. Não se trata de dizer que as mé- 
tricas e os controles não sejam importantes. Podemos dizer até que são muito 
importantes, mas as métricas deveriam servir também para outras finalida- 
des: validar, direcionar, justificar e dirigir. Porém, nem sempre isto acaba 
acontecendo. Muitas métricas acabam sendo definidas, criadas e mantidas ao 
longo das atividades de gestão de serviços de TI, mas não são efetivamente 
usadas para dirigir ou direcionar ações corretivas. Na maior parte das vezes 
são usadas para justificar. Justificar atrasos, justificar aumento nas filas, jus- 
tificar perda de produtividade, justificar falhas. 

Muitas métricas são geradas, comparadas, listadas, apresentadas aos 
clientes, mas eles em vez de se sentirem confortados pelos números acabam 


se sentindo confusos e se perguntando: “Ok, a quantidade de chamados de 
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incidentes atendidos no mês dobrou, mas e daí? Será que isto foi bom ou 
mal? E o que minha área deve fazer com relação a isto?” 

O cliente não quer números; quer indicadores. Para muita gente isso parece 
a mesma coisa. Aqui vamos apresentar uma visão que talvez seja ligeiramente 
diferente do que a ITILº apresenta. Ao final de cada um dos processos da 
ITIL® sempre aparece um item chamado “ndicadores-chave de Desempenho” 
(os KPIs — Key Performance Indicators). Pois bem, eles poderiam ser chama- 
dos de Métricas-chave de Desempenho, pois muitos são somente medidas. 

Por exemplo, vamos pegar o indicador clássico de incidentes que é o per- 
centual de incidentes encerrados no prazo, ou quem sabe até a quantidade de 
incidentes encerrados no prazo. A maior parte das pessoas (e até a TTILº) 
diria que isto é um indicador de desempenho. Para nós, não passa de uma 
métrica, se for analisada isoladamente no mês. 

Que indicação de desempenho teremos se soubermos que o percentual 
foi 85% e que a quantidade foi 1.100? Isto é um bom ou mau desempenho? 
Depende do valor de referência esperado. Se todo mês temos um percentual 
superior a 90% com uma quantidade superior a 1.800 e este mês tivemos só 
50% com 1.000 incidentes encerrados no prazo, então agora eu tenho um 
indicador de desempenho: desempenho abaixo do esperado, desempenho 
ruim, desempenho caindo; e mais: precisamos aumentar a equipe, ou treinar 
as pessoas, ou melhorar nossa base de soluções de contorno, ou atuar no pro- 


cesso de resolução, enfim, definir e executar ações. 


TABELA 1 
% incidentes encerrados Qtde. incidentes encerrados 
Mês no prazo no prazo 
n-2 95 2.000 
n-1 93 1.970 
n 85 1.100 


Valor de referência: 80%; 1.000 chamados 


Quantidades e percentuais mensais (ou de qualquer outra frequência) 
isolados deveriam ser chamados de métricas de desempenho. Quantidades 
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e percentuais mensais comparados a valores de referências ou entre si 


(com séries históricas), dariam origem a indicadores de desempenho. 


LIÇÃO APRENDIDA: Um ambiente controlado através de métricas não é suficiente 
para agregar melhorias. Estas métricas têm que se transformar realmente em in- 
dicadores de tendência (melhorando, piorando, estável) e propiciar a seleção de 
ações corretivas dentre as alternativas existentes. 


O que queremos? Maior controle sobre os recursos 


Ao se falar de gestão de serviços de TI com pessoas que não conhecem 
a ITILº e, portanto, também não conhecem o correto conceito de serviço, 
corremos o risco de que muitos pensem: “Ah, você está falando que irá ter 
gestão sobre aquilo que a TI faz, sobre os serviços que ela realiza, sobre as 
atividades que executa.” Não é difícil ver pessoas falando sobre gestão de ser- 
viços, imaginando pessoas executando atividades. Mas nós que conhecemos 
a ITIL® sabemos que um serviço não é algo que se executa ou que se faz. 
Um serviço é algo que se entrega (lembre-se do service delivery da V2) para 
ser aplicado como facilitador para o atingimento de objetivos de negócio. 
Mas deixemos a teoria de lado e vamos ver qual é o desvio de objetivos que 
acontece aqui. 

Quando alguém pensa em implantar a GSTI para, com isso, ter mais 
controle sobre recursos, pode acabar novamente se concentrando dema- 
siadamente em aspectos internos da TI, principalmente naqueles associa- 
dos à execução de tarefas. O termo recurso é inclusive um termo usado 
em metodologias de gerenciamento de projetos para representar pessoas 
alocadas em atividades, o que pode reforçar ainda mais a visão errônea de 
que a gestão de recursos na ITIL® está intimamente ligada à gestão de 
pessoas. 

Se voltarmos à teoria, vamos lembrar que, como Ativos de Serviços (Ser- 


vice Assets), realmente vamos lidar com as pessoas e perceberemos que elas 
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precisam ser gerenciadas, assim como os demais recursos lá citados. Porém, 
perceba uma coisa: na TTILº V3 não temos um processo associado à Gestão 
de Equipes, Gestão de Pessoas, Gestão de Força de Trabalho ou coisa pa- 
recida. Talvez na ITILº V4 tenhamos um processo novo com este objetivo. 
Já os processos de gestão financeira, gestão de capacidade, gestão de dispo- 
nibilidade, gestão de segurança da informação e tantos outros dão suficiente 
suporte para a gestão dos demais recursos citados na ITILº (recursos finan- 


ceiros, infraestrutura, aplicações e informações). 


Capacidades Recursos 


Gerenciamento Capital financeiro 
Organização Infraestrutura 


Processos Aplicações 


Conhecimento Informação 


PESSOAS 


Que processo na ITILº referencia o gerenciamento de “pessoas”? 


Recomendo, portanto, que, desde as fases de início e contágio, ao se ex- 
plorar o conceito de que a ITILº é um poderoso instrumento para a ges- 
tão de recursos, incluam-se neste discurso todos os recursos, e não só os 
humanos, pois isso poderá inclusive ser um facilitador no engajamento de 
mais pessoas em seu plano. Outro destaque importante que pode ser dado ao 
tema é a visão de que os recursos de que estamos falando são os oferecidos 
aos clientes em forma de serviços: recursos de segurança, de automação, de 
melhoria de desempenho para as áreas de negócio etc. Este também será um 
discurso que despertará o interesse dos clientes. Eles ficarão satisfeitos em 
saber que a TI busca meios para gerenciar os recursos que está oferecendo, 


ou deixando de oferecer, às suas áreas de negócio. 
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Para obter o controle de recursos podemos explorar diversos processos 
ITILº simultaneamente, porém, muitos acabam concentrando-se demasia- 
damente na gestão de capacidade quando este é o assunto. É importante 
lembrar que, mais do que o controle reativo, devemos nos concentrar no 
controle preventivo dos recursos. E o que isto significa? Que mais do que 
controlar o que está sendo usado, devemos controlar o quanto temos para 
oferecer e o que pode ser utilizado. 

Muitos devem estar pensando: “Bom, isso também é papel da gestão de 
capacidade quando faz o Plano de Capacidade.” É verdade, mas gostaria de 
voltar um pouco mais no tempo. Acredito que o controle de recursos comece 
bem mais cedo, lá na fase de desenho de um serviço. Talvez até antes, na 
fase de estratégia do serviço. Existe um termo na ITIL® que é muito impor- 
tante: “Influenciar a demanda.” Esta denominação parece perfeita. Não se 
trata de restringir a oferta, mas de ofertar efetivamente aquilo que é possível, 
negociando, entendendo, esclarecendo e ajustando os recursos que temos às 
demandas que nos são apresentadas. 


demanda Na A 
/ a E” 


Se não houver um cuidado com o controle de recursos a oferecer desde as 
fases mais iniciais da concepção de um serviço, então nosso papel de contro- 
ladores vai se parecer mais com um “gerenciamento do caos” do que qualquer 
outra coisa. Vamos ser capazes de medir o quanto temos de saturação dos re- 
cursos, o quanto temos de retenção de demandas por falta de recursos, o quan- 
to os níveis de serviços são afetados por falta de recursos, quando que muito 


disso poderia ter sido evitado em uma fase de planejamento antecipada. 
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Neste caso se aplica uma regra que diz: “Para oferecer não precisa ter, mas, 
se oferecer, precisa entregar.” Isto se aplica muito bem à gestão de serviços e 
ao compromisso que assumimos com a sua entrega (e de recursos) a nossos 
clientes. Portanto, pense bem nos compromissos que você está assumindo 
quando define a estratégia e o desenho de um novo serviço. 

É nessa hora que o controle de recursos deve realmente começar, e, para 
isso, realmente a ITILº se aplicará muito bem. Agora, se você só pensa 
em métricas e indicadores gerados na fase de operação do serviço para 
avaliar se os recursos estão ou não sendo suficientes, talvez precise reava- 
liar sua estratégia. Realizar medições somente no final do ciclo de vida do 
serviço deve ser o compromisso daqueles que, tendo planejado, precisam 
confrontar o previsto com o realizado para aprender lições que permitirão 
agregar melhorias contínuas no processo de controle de recursos, e não 
para aqueles que precisam descobrir o que fazer para reparar os desvios 
gerados. 

Já não fosse tudo isto complexo o suficiente, é bom sempre lembrar que 
quando falamos de controle de recursos na ITILº podemos estar tendo três 
visões distintas que nascem da gestão da capacidade: a capacidade do ne- 
gócio, a capacidade do serviço e a capacidade do componente. Novamente 
aqui, muita gente é muito boa em controlar a capacidade dos componentes 
sabendo “na ponta do lápis” quanto espaço em disco ainda possui, quanto da 
memória de seu servidor está em uso etc. E acham que isso é um controle 
de recursos suficiente. Não é. Se você não conseguir avaliar se estes recursos 
dos componentes estão efetivamente produzindo recursos de serviços e se os 
recursos de serviços estão produzindo recursos de negócio, então ainda há 


um bom caminho a trilhar pela frente. 


LIÇÕES APRENDIDAS: O controle de recursos não deve ser uma atividade reati- 
va, criada somente depois que eles já existem. Este tipo de controle é típico da 
gestão de infraestrutura e não da gestão de serviços. Na gestão de serviços pre- 
cisamos deixar de avaliar apenas a capacidade dos recursos e começar a avaliar 
a capacidade dos serviços. 
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O que queremos? Melhoria do serviço prestado 


A menção à “melhoria dos serviços prestados” também figura entre os 
principais objetivos que muitas áreas de TI buscam quando “implantam a 
ITIL®” (sic). Por tudo o que já apresentamos até aqui, fica claro que este 
objetivo precisa de um realinhamento. É compreensível que a TI busque 
executar suas atividades de modo mais eficiente e eficaz. É desejável que 
atenda melhor a seus clientes. Devemos então destacar não a prestação de 
serviços, mas a entrega de serviços através de melhores processos. Destacar 
a melhoria nos processos, sejam internos ou externos, é o ponto-chave do 
sucesso. 

Se novamente relembrarmos a teoria, vamos ver que ao nos concentrar- 
mos não em serviços executados, mas em processos executados para entregar 
serviços, teremos a chance de fazer uma abordagem muito mais formal do 
assunto. Poderemos analisar, definir e redefinir entradas, saídas, atividades, 
agentes executores, papéis, matriz RACI, políticas, documentos, recursos 
etc. 

Prudente neste tópico seria recomendar que se trocasse a palavra “pres- 
tado” pela palavra “entregue”. Uma pequena mudança como esta pode sig- 
nificar grande melhoria na capacidade de captar patrocinadores para nossos 
projetos. Se você conseguir criar a cultura nos clientes de que a TI entrega- 
rá serviços e que, nestes serviços entregues, teremos pacotes compostos por 
equipamentos, softwares, infraestrutura, treinamento etc., então, talvez ha- 
vendo uma insatisfação sobre qualquer um destes itens, o cliente perceba que 
terá uma oportunidade de corrigir as deficiências naquilo que receberá da TI 
se apostar numa iniciativa de gestão de serviços que ofereça a “melhoria nos 


serviços entregues”. 


TI SEM ITILº TI COM ITILº 
SERVIÇO PRESTADO SERVIÇO ENTREGUE 
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A TI tem um desafio constante de demonstrar que a qualidade dos servi- 
ços que entrega está dentro dos parâmetros esperados. E por que isto? Por- 
que a própria avaliação da qualidade é um desafio. Se você não é capaz de 
coletar indicadores de qualidade precisos, então não consegue demonstrar 
também precisamente esta qualidade. 

Normalmente, quando se fala em avaliar a qualidade, a primeira ideia que 
nos vem à cabeça são as pesquisas de satisfação. À linha de raciocínio parece 
simples: se temos clientes e desejamos saber se os estamos atendendo com 
qualidade, então devemos perguntar diretamente a eles, certo? Errado. A 
qualidade em vários segmentos (não só nos serviços de TT) tem de ser vista 
sob dois aspectos: sua existência e sua percepção. 

Muitas iniciativas de qualidade são feitas para agregar qualidade e não 
para demonstrá-la. Isso pode gerar um paradoxo: nosso serviço tem quali- 
dade, mas nossos clientes não são capazes de percebê-la. Isso com certeza 
não é uma regra em todos os casos. Existem aspectos da qualidade que po- 
dem ser facilmente percebidos quando são agregados, porém outros não. Por 
exemplo, se você criar uma iniciativa para agregar melhorias de qualidade no 
processo de atendimento de solicitações, tornando-o mais simples, talvez seu 
cliente perceba imediatamente e acuse a melhoria. Já se você fizer melhorias 
no processo de gerenciamento do serviço (que é algo que acontece na reta- 
guarda e o cliente não vê), talvez seu cliente nunca reconheça que este esforço 
foi feito e que a qualidade aumentou. 

Mas afinal o que é importante? Ter qualidade ou transmitir qualidade? 
As duas coisas juntas. Primeiro porque para transmitir é preciso ter, e depois, 
porque se tiver e não transmitir o cliente não saberá que você tem. Isto nos 
faz voltar ao tema das pesquisas de satisfação e do porquê de elas falharem, se 
mal aplicadas, no sentido de produzir indicadores de qualidade dos serviços 
que estamos entregando. 

Se você aplicar uma pesquisa de satisfação em um ambiente em que a per- 
cepção de qualidade é baixa, poderá obter um indicador de qualidade baixo. 
Isto não significa que seu serviço não tem qualidade. Significa somente que o 
cliente não consegue perceber esta qualidade e que, portanto, na visão dele, a 


qualidade é baixa. Isso não significa que as pesquisas de qualidade não devam 
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ser aplicadas. Devem, porém é importante que sejam direcionadas para me- 
dir elementos concretos. 

Se avaliarmos alguns formulários de pesquisa de satisfação que normal- 
mente são enviados no encerramento dos chamados que atenderam a uma 
solicitação, veremos, muitas vezes, que a coleta de informação que eles per- 
mitem é subjetiva. 

Um exemplo de uma pergunta que constantemente é vista nestes formu- 
lários é: “Que nota você dá para o atendimento recebido?” Não importa se 
a nota é de zero a dez ou se ruim, regular, bom, ótimo, excelente. Não são 
as opções de resposta que são ruins, mas a pergunta que é subjetiva. Por que 
subjetiva? Porque, com exceção da nota 10 ou do conceito excelente, todos os 


demais nos deixarão com mais dúvidas do que esclarecimentos. 


Que nota você daria para nosso 
atendimento? 


TI 


CLIENTE 
Onde foi que nós falhamos? 


Alguém que dá o conceito bom ou a nota 8 para um atendimento recebi- 
do está nos indicando o quê? Que existe algo a melhorar, alguns diriam. Sim, 
mas o que deve ser melhorado? Não sabemos e continuaremos sem saber. Se, 
por exemplo, entrevistássemos a pessoa que deu esta nota 8 e perguntássemos 
por que o conceito não foi 10, ela poderia dizer que “não gostou do horário 
em que o técnico fez o atendimento, pois era muito cedo, e pela manhã ela 
prefere fazer atividades sem a presença de um técnico na sua sala”. 

Já outro cliente que também deu nota 8 poderia dizer que “não gostou do 
atendimento pois o técnico executou várias atividades na sua máquina, mas 
não explicou nada do que estava fazendo apesar de ter realmente resolvido 


o problema”. Isso demonstra que não gostar totalmente de um atendimento 
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recebido é um critério subjetivo. Precisaríamos de perguntas mais específicas 
para ter elementos que realmente gerem oportunidade de melhoria. Afinal, 
adianta você saber que algo não está bom para o cliente se você não sabe exa- 
tamente o que deve ser melhorado? Elaborar bons formulários de pesquisa 
de satisfação é uma ciência. Alguns diriam até que é uma arte. 

Um bom embasamento para este tema pode ser encontrado em “The 7-S- 
tep Improvement Process” do livro de CSI (material oficial da ITIL®). Já no 
passo 1 deste processo, que se trata de “O que se deseja medir?”, podemos 
receber boas dicas sobre como elaborar nossos formulários de pesquisa de 
satisfação. No exemplo que demos anteriormente, se seu objetivo é só saber 
se existe algo a ser melhorado, então a pergunta “Que nota você dá para o 
atendimento recebido?” é perfeita. Você rapidamente descobrirá que 80% 
das pessoas acham que ainda há algo a melhorar, pois não deram nota 10 
ou conceito excelente. Seu objetivo foi atingido quando você descobriu que 
ainda há algo a ser melhorado. 

Mas, cá entre nós, este não seria um bom objetivo. Você muito prova- 
velmente deseja saber mais. Então precisa definir novamente “o que se de- 
seja medir” (passo 1) e depois descobrir “o que se pode medir”, e assim por 
diante. Você irá descobrir que efetivamente o que deveria ser medido não é 
a quantidade de pessoas insatisfeitas, mas quais são os itens que mais geram 
insatisfação. Só assim você poderá atuar sobre estes itens e corrigir as de- 


ficiências existentes. 


LIÇÕES APRENDIDAS: Medir os aspectos de qualidade de um serviço pode não 
ser uma atividade trivial. Avalie aspectos objetivos. Evite aspectos subjetivos. Se 
você precisa de informações úteis, então não seja generalista. 


QUEM DEVE BUSCAR OS RESULTADOS? 


O que podemos facilmente constatar é que as pessoas que fazem um cur- 


so de fundamentos de ITILº saem convencidas de que realmente há muito 
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a ser melhorado em seus ambientes de trabalho. Que muitas das melhores 
práticas vistas podem ser colocadas em prática em seus processos. Apesar de 
não ser uma regra, temos visto que a maior parte das pessoas que participam 
dos cursos de ITIL Foundationsº são pessoas ligadas ao processo de aten- 
dimento e suporte a usuários, entre eles coordenadores, analistas de suporte, 
atendentes, pessoal de sistemas etc. 

É menos frequente, porém, encontrarmos CIOs ou até diretores de TI 
nestes cursos. Uma explicação para isso é que a ITILO é vista, por muitos, em 
princípio, como uma abordagem técnica para melhorar o suporte a usuários. 
Logo, nada melhor do que enviar os envolvidos com o suporte para aprende- 
rem sobre isso e, voltando ao seu ambiente de trabalho, implantarem as tais 
medidas de melhoria. Mas isso não funciona. 


GESTÃO DE 
ITILO SERVIÇOS > io 


DE TI 


Aqueles que ministram cursos de ITILO já devem ter percebido que é 
muito difícil conseguir a concentração de toda a turma em todas as fases 
do ciclo de vida do serviço. A parte estratégica e o começo do módulo de 
desenho do serviço são assuntos que falam diretamente para os gestores. Só 
depois, na transição e operação, é que se tem um perfil “consumível? pelo 
pessoal de suporte. Depois, novamente no ciclo de vida da melhoria contí- 
nua, voltamos ao perfil gerencial. 

Como estes cursos abordam fundamentos, todo mundo acaba por se 
adaptar aqui ou ali em cada fase do ciclo. Isto só reforça a ideia de que os 
gestores de TI também poderiam ganhar muito se participassem de um cur- 
so de “Gestão de Serviços de TP” (mesmo sem pensar na certificação), afinal 
são eles que patrocinarão as grandes mudanças dentro da organização (como 
vimos no Capítulo 1) e também as mudanças dentro da TI que apresentare- 


mos a seguir. 
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Hoje ainda temos uma barreira a transpor. Para agregar as melhores práti- 
cas da TTILº na operação dos serviços, precisaremos de iniciativas em todas 
as demais fases do ciclo de vida do serviço, e muitas vezes não encontramos 
o patrocínio para estas iniciativas. Queremos os resultados já citados, mas 
não teremos condições de obtê-los sem um comprometimento global da TI. 
Não se trata só de novas técnicas. Não se trata de uma ou outra área da TI 
adotar um novo processo. Estamos falando de um novo modelo de gestão! 
De mudanças na empresa para receber este novo modelo de gestão. Se uma 
ou outra área dentro da TI (sistemas, infra, operação, service desk, gerências 
etc.) não adotar simultaneamente este novo modelo de gestão e de entrega 
de serviços teremos futuros conflitos. 

A analogia poderia ser a seguinte: imagine como numa indústria seria 
possível ser adotado um modelo “just-in-time” para a área de produção se a 
área de compras, a área de estoque, a área de distribuição e até a equipe de 
vendas não mudassem também seus processos para se adaptar ao novo mo- 


delo. Daria certo? 


LIÇÕES APRENDIDAS: A maior barreira a ser superada na gestão de serviços de 
TI não são as questões operacionais, mas as questões gerenciais. As mudanças 
devem começar nos níveis gerenciais, afinal estamos falando em gestão de ser- 
viços. 


QUE ÁREAS SERÃO AFETADAS DENTRO DA TI? 


Existem, claramente, duas grandes áreas, ou níveis, que são afetados pela 
adoção de um modelo de gestão de serviços de TI baseado na TTILº: a 
área operacional e a área gerencial, não necessariamente nessa ordem. Va- 
mos apresentá-las assim, pois é a maneira mais habitual de se perceberem as 
mudanças. À área operacional, inclusive, é a área que normalmente detecta a 
necessidade da mudança de paradigma impulsionada pelo nível de satisfação 
dos clientes com os serviços recebidos. 
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ESCOPO GERAL DA ITILº 


ÁREA OPERACIONAL ÁREA GERENCIAL 


Operacional 


Dentro da área operacional, mais especificamente na área de suporte a 
usuários (termo ainda comumente usado antes de a visão ITILº ser adota- 
da), é que teremos a primeira grande mudança. Como já dissemos no capítu- 
lo anterior, não estamos falando da mudança de denominação de “help desk” 
para “service desk”, mas da mudança do papel que a área exercerá. 

O papel tradicional que uma área de suporte tem é a de fornecedora de 
tecnologia, especificamente hardware, software e infraestrutura. Como for- 
necedora destes itens, ela assume também o papel de “consertadora” de to- 
dos os defeitos e de “esclarecedora” de todos os tipos de dúvidas que estes 
recursos geram. O novo papel que se espera desta área é que ela garanta a 
restauração dos serviços o mais rápido possível. O termo “garantir a restau- 
ração” tem uma abrangência bem extensa, mas em resumo significa “garantir 
que o cliente de um serviço possa estar constantemente aplicando-o aos seus 
processos de negócio com o menor grau de interrupções possível, seja por 
dúvidas, por falhas, por degradação etc.” 

Para quem participa de um curso de ITIL Foundations”, este conceito 
parece trivial, mas e para as demais pessoas de nossa equipe, será que isso está 
claro? Pode parecer a eles, numa primeira análise, que o objetivo é o mesmo 
do bom e velho help desk, mas não é. Precisamos destacar (e convencê-los 
de) que a primeira mudança é que o objetivo não é mais consertar itens de 
hardware ou software, mas sim restabelecer o serviço. Isso faz toda a diferen- 
ça no foco das atividades. 

Quase todos nós fomos treinados um dia para procurar as causas das fa- 
lhas e depois aplicar o conhecimento técnico para consertá-las. Aprendemos 


que se algo quebra então temos que arrumar. Este é o conceito de efetividade 
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que a maior parte das pessoas tem e pelo qual irão continuar a se guiar se não 
fizermos nada para mudar. 

Mudar, então, o conceito de efetividade será muito importante para toda 
a equipe. Não precisamos mais só de pessoas que sejam boas em consertar 
aquilo que quebra. Precisamos de pessoas boas em saber fazer o cliente voltar 
a operar quando qualquer interrupção é gerada na sua operação. Pode ser que 
não saibamos consertar as coisas, mas podemos ser muito bons em encontrar 
soluções de contorno que façam o cliente voltar ao trabalho normalmente! 
Este é o primeiro sentimento que deve ser desenvolvido na equipe. Em to- 
dos. “Se você não conserta e também não propõe soluções de contorno, mas 
auxilia para que elas possam ser colocadas em prática, então você é efetivo 
e você contribui para o objetivo principal de nossa área. Você é efetivo para 
o negócio da empresa.” Esta é a mensagem que deve ser transmitida a cada 


um da equipe. 


PERFIL DA GESTÃO DE SERVIÇOS DE TI 


CONS p RESTABELECER UM SERVIÇO 


Com esta mudança, podemos esperar alguns conflitos naturais. Estamos, 
de certo modo, inibindo a atuação, num primeiro momento, dos especialistas 
que, normalmente, gostam de se “debruçar sobre novas falhas” e ali ficar até 
que uma “solução genial” seja identificada, para receber as merecidas “me- 
dalhas”. 

Não queremos mais, num primeiro instante de uma falha detectada, que 
um interminável processo de investigação seja iniciado, mesmo que por nos- 
so mais competente especialista. Queremos agilidade. Queremos que uma 
solução de contorno seja rapidamente identificada e que nosso cliente volte 
a trabalhar. Para um especialista, falar em “solução de contorno” soa, no co- 
meço, como pedir a um grande pintor que faça uma “caricatura num papel 


de embrulhar pão”. 
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Este é o desafio que temos de enfrentar: procurar demonstrar a cada 
um qual seu novo papel, qual o processo no qual será inserido e quando ele 
poderá usar suas “habilidades ninja”. Neste exemplo, precisamos mostrar 
que haverá um momento em que os especialistas serão muito requisitados 
e úteis, terão muito tempo para produzir soluções geniais e serão muito 
recompensados por isso: na gestão de problemas, mas não na gestão de 
incidentes. 

Outros conflitos similares poderão surgir com outras pessoas em outros 
papéis e funções. Áreas de apoio e retaguarda também poderão se colocar 
muitas vezes “na defensiva”, imaginando que a TI está procurando impor 
novas regras e novos processos que as fazem se sentir subordinadas à TI. 
Imagine-se negociando um ANO (Acordo de Nível Operacional) com outra 
área dentro da organização, em uma fase inicial de implantação destas mu- 
danças no ambiente. Deverá haver muita resistência da área solicitada pela 
TI, principalmente se ela perceber que a TI está procurando impor exigên- 
cias quanto a prazos, condições, recursos etc. para serviços que a outra área 
terá que oferecer. 

Superar este conflito requer que as iniciativas comentadas no Capítulo 1 
sejam implementadas. A área solicitada pela TI através deste ANO não esta- 
rá na verdade prestando nenhum serviço à TI, mas sim prestando um serviço 
para cada um dos solicitantes aos quais a TI atende. Talvez o chamado que 
requeira a ativação deste ANO seja do presidente da empresa, do diretor 
financeiro, do diretor da própria área envolvida no ANO ou até da própria 
pessoa que está criando resistência à mudança do processo. Isso faz parte da 
visão corporativa de que falamos anteriormente. 

Esta visão corporativa deve também ser refletida, em menor escala, den- 
tro da estrutura da TI. Como já dissemos, a implantação da Gestão de Ser- 
viços de TI requererá um envolvimento por completo de todas as áreas da 
TI. Neste sentido, algumas novas atividades podem ser necessárias. Muitas 
vezes a área que será requisitada para executar uma determinada nova ati- 
vidade poderá não ver no seu escopo de atuação qual é a necessidade de 


executar tal tarefa. Pode até considerar somente alocar tempo e recursos 
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de sua equipe sem trazer resultados diretos para si. Isso pode realmente 
acontecer. À atividade pode não gerar nenhum produto específico para sua 
finalidade de atuação, mas, com certeza, produzirá um produto que será 
importante dentro de um processo executado em outra área e que determi- 
nará resultados. 


NOVOS NOVAS 
PROCESSOS SAÍDAS 


NOVAS 


ENTRADAS (TAREFAS) (RESULTADOS) 


Um exemplo desta situação poderia ser o caso em que a equipe de infraes- 
trutura seja solicitada a registrar no sistema do service desk, com antecedência 
de uma semana, pelo menos, todas as interrupções de serviços programadas 
para o fim de semana. Talvez eles argumentem que já têm este controle em 
outro tipo de interface (um quadro de avisos internos, uma agenda do grupo 
ou uma planilha, por exemplo) e que registrar novamente estas informações 
em outro lugar seja uma mudança de processo na qual eles não veem vanta- 
gem ou que irá gerar retrabalho desnecessário. 

Nesta situação, talvez, os controles que a equipe de infraestrutura já 
possui sejam suficientes para que eles executem seus processos internos. 
Porém, se eles não compartilharem a informação com o restante dos en- 
volvidos em outros processos, a TI, como um todo, deixará de tê-los cor- 
retamente operados. Neste momento, o espírito corporativo e a visão de 
processos interligados devem ser destacados a todo o grupo e cada um 
deve identificar seu papel num escopo maior do que somente o de sua área 
restrita de atuação. 


LIÇÕES APRENDIDAS: Prepare-se para enfrentar conflitos na área operacional. É 
natural que eles surjam se as pessoas envolvidas nos processos não identificarem 
exatamente o que se espera delas neste novo cenário. 
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Gerencial 


Falamos até aqui de áreas operacionais afetadas pela implantação da ges- 
tão de serviços de TI. À visão de que a ITILO irá gerar impactos nas áreas 
operacionais é mais clara, pois ela é um paradigma baseado em processos e, 
ao falar de processos, logo nos parece que temos só um enfoque operacio- 
nal. Não podemos, entretanto, deixar de lembrar que, para cada processo 
operacional desenvolvido, também pela visão da ITIL®, deveremos ter um 
processo de gestão associado. Toda a visão da ITILO é baseada em indica- 
dores, gestão de resultados, avaliação e busca de melhorias contínuas. Estes 
aspectos todos destacam sem dúvida que os processos gerenciais e as áreas 
gerenciais também serão afetados. 

O primeiro impacto nas áreas gerenciais que podemos destacar é a criação 
de políticas e mecanismos de controle baseados em resultados. Isso significa 
que as métricas definidas e controladas precisam ser muito mais qualitativas 
do que quantitativas. 


VISÃO TRADICIONAL VISÃO GESTÃO DE SERVIÇOS DE TI 


MÉTRICAS QUANTITATIVAS MÉTRICAS QUALITATIVAS 


Historicamente, e por formação de muitos, fomos criados para ter uma 
visão quantitativa em primeiro lugar. Alguns gerentes ainda estão tão preo- 
cupados com o cumprimento dos horários de trabalho pelas equipes que não 
têm tempo para estabelecer e monitorar métricas de resultados qualitativos 
nestas mesmas equipes. 

A busca do equilíbrio entre métricas qualitativas e quantitativas deve ser, 
então, o primeiro desafio a ser superado pelas gerências. Podemos, sim, con- 
trolar quantas horas um funcionário aloca por dia, o horário em que che- 
ga, em que sai, o intervalo de almoço que faz. Mas precisamos saber se ele 
está sendo efetivo (já discutimos isso anteriormente), útil, engajado, se tem 


evoluído, se tem agregado valor aos nossos processos. Demos um exemplo 
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baseado no controle de horas trabalhadas, mas esta mesma abordagem vale 
para todos os demais controles nos quais as gerências participam. 

Mesmo em ambientes que já adotam as melhores práticas da ITTL®, exis- 
tem discussões sobre níveis de SLA não atendidos que são totalmente desfo- 
cadas do aspecto qualitativo. São reuniões mensais nas quais se discute qual 
o percentual de SLA atingido ou não, e em que se acaba perdendo a visão 
qualitativa em prol da visão quantitativa. Pessoas comparam o SLA deste 
mês com o SLA do mês anterior ou com a meta de SLA a ser cumprida. Se 
o nível foi atingido, ótimo. Se não foi, penalizações poderão ocorrer, princi- 
palmente se quem está sendo monitorado for um terceiro. 

Não podemos dizer que não deva existir tal controle, mas deveríamos 
esperar que ele fosse equilibrado com a visão qualitativa de que deveríamos 
sentar e avaliar cada um dos chamados que levaram ao não atingimento 
geral do SLA para “aprender lições”. Assim, quanto mais lições aprender- 
mos num determinado mês sobre o que podemos mudar ou melhorar para 
que os futuros SLAs sejam atingidos, mais o nosso indicador qualitativo 
crescerá. 

Esta visão de indicadores qualitativos tem total aderência com a visão de 
melhoria contínua proposta pela ITILº apesar de não aparecer explicita- 
mente em nenhum quadro de sugestão de indicadores de desempenho (KPI) 
em qualquer dos processos nos livros da ITIL®. Se em determinado ponto 
do ciclo de vida do serviço não encontrarmos pontos a melhorar, então nosso 
indicador qualitativo será reduzido. 

Precisamos encontrar pontos a melhorar. Não significa que encontrar fa- 
lhas seja bom. Significa somente que encontrar falhas é uma oportunidade 
de encontrar pontos a melhorar, por isso, quanto mais oportunidades pode- 
mos encontrar, mais qualidade poderemos agregar. Podemos fazer uma as- 
sociação entre busca de melhoria contínua e o processo de testes de software. 
Quem já estudou algo sobre Engenharia de Software e sobre o tema de testes 
de software já deve ter ouvido algumas frase tais como: “Nunca podemos 
assegurar que um programa está livre de erros. Se não os encontramos não 
significa que eles não estejam lá, apenas que não os encontramos”, ou então: 


“Um teste que não tenha encontrado erros não foi um teste que teve sucesso. 
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Ele na verdade fracassou, pois seu objetivo era encontrar erros”, entre muitas 
outras parecidas. 

Esta visão de indicador qualitativo pode ser agregada a praticamente to- 
dos os processos ITILº e a todas as atividades que eles comportam. Talvez 
na gestão de incidentes o fato de encontrarmos incidentes para os quais uma 
solução de contorno equivocada tenha sido aplicada possa nos mostrar opor- 
tunidades, de melhoria em nossa base de conhecimento. Isto significa que 
não devemos simplesmente medir ao final do mês quantos chamados foram 
reabertos ou qual foi o índice de reincidência de um incidente para o mesmo 
equipamento, mas que devemos identificar por que isso ocorreu e quantas 
oportunidades de melhoria no processo nós conseguimos identificar. Quanto 
mais oportunidade encontrarmos, melhor será nosso indicador qualitativo 
relativo ao item. 

Porém não adianta somente que o gestor tenha a nova visão. É neces- 
sário que ele consiga repassá-la a suas equipes e que crie uma nova visão 
de avaliação de desempenho. Também no que diz respeito à avaliação de 
desempenho das equipes o conceito de indicadores quantitativos e qualitati- 
vos será importante. Alguns gestores ainda trabalham com indicadores tais 
como quantidade de chamados atendidos por técnico, tempo total alocado 
do técnico na resolução de chamados, chamados encerrados por técnicos etc. 
Estes são todos indicadores quantitativos. E quais seriam então os indicado- 
res qualitativos? Por exemplo: aumento da efetividade da base de conheci- 
mento, pontos de melhoria apontados nos processos, quantidade de soluções 
de contorno sugeridas etc. 

Ainda temos muita parte de nossa cultura de controle de recursos huma- 
nos baseada em indicadores quantitativos. Aquele agente que executa maior 
número de transações nas atividades-fim dos processos nos quais está in- 
serido ainda continuará a ser visto como o de maior efetividade. Mas, por 
tudo o que já apresentamos até aqui e pela visão de resultados para o cliente 
que precisamos incorporar com a ITILº, precisamos estar disponíveis para 
absorver novos conceitos. 

Talvez ficar atentos para a tentativa de identificação de quais seriam os 


indicadores que nos mostrariam aqueles agentes que, de um modo ou de 
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outro, mais contribuíram para que os serviços fossem entregues de acordo 
com as necessidades dos clientes e que fossem mantidos em operação dentro 
dos níveis de serviço acordados. Talvez um novo processo a ser agregado na 
ITILº nos ajudasse a tratar este tema: a Gestão de Equipes. Com certeza 
neste processo apareceriam sugestões de indicadores qualitativos para avalia- 
ção da atuação das equipes nos diversos processos. Vamos aguardar. 

Outro impacto para a área gerencial que podemos avaliar é seu novo pa- 
pel de influenciadora ou patrocinadora da TTIL* (ou da gestão de serviços 
de TI) na organização. Neste aspecto, não está só incluída a área gerencial 
de nível médio, mas também a área gerencial de alto nível. Muito se ouve 
falar da necessidade de alinhamento estratégico da TI com a organização. 
Este é um discurso que nasce com o Cobitº e que chega até a TTILº e que 
deve deixar de ser um simples discurso para se transformar em melhores 
práticas. 

Já dissemos que a organização deve reconhecer o novo papel da TI. A 
responsabilidade para fazer com que isso aconteça é, em grande parte dos 
níveis gerenciais, da própria TI. Não se trata só de alinhar objetivos estraté- 
gicos. É preciso que a organização reconheça na TI não uma área provedora 
de tecnologia, mas uma área de Gestão de Serviços, com todas as prerroga- 
tivas das demais áreas de gestão tais como Recursos Humanos, Financeira, 
Materiais, Produção etc. Existem empresas em que os técnicos, por terem 
conhecimento da TTILº na faculdade, na mídia, na internet ou em cursos, 
estão fortemente motivados para transformar o ambiente no qual se inserem. 
Porém, os níveis gerenciais continuam a colocar a TI como simples prove- 
dora de tecnologia que acaba por ter sua própria atividade direcionada pelos 
interesses das demais áreas. 

É verdade que devemos servir como facilitadores para as demais áreas. 
Porém, também é verdade que precisamos elevar o nível da gestão, saindo da 
gestão de tecnologia e atingindo a gestão dos serviços. No momento em que 
os gestores de TI forem os primeiros patrocinadores desta visão na organiza- 
ção, defendendo, argumentando, negociando e até impondo novas condições 
de participação da TI nos processos de negócio da empresa, teremos, então, 


uma “alavanca para mover o mundo”. 
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LIÇÕES APRENDIDAS: Diversas mudanças precisarão ser absorvidas também pe- 
los níveis gerenciais. Busque desde o início da implantação da gestão de serviços 


de Tl transmitir estes conceitos aos níveis gerenciais. 


QUE OUTRAS ÁREAS SERÃO AFETADAS ALÉM DA TI? 


Já comentamos que a organização de modo geral será afetada, pois, como 
clientes da TI, eles passarão a ter um novo tipo de relacionamento e um novo 
papel nos processos em que estiverem inseridos. Já comentamos também que 
haverá um novo tipo de relacionamento que afetará as áreas provedoras de 
serviços para a TI através dos acordos de nível operacional (ANO). Vamos 
abordar agora mais uma modificação nos relacionamentos imposta pela im- 
plantação da gestão de serviços de TI. 

A TI, para prover os serviços a seus clientes, conta com, além de suas 
equipes próprias e de provedores de serviços internos, fornecedores externos, 
sejam eles fornecedores de serviços ou de recursos (peças, suprimento, re- 
cursos humanos, tecnologia, conhecimento etc.). Estes, que ainda na TTILO 
V2 apareciam somente vinculados a contratos com a TI, ganharam, agora na 
V3, um importante destaque através de um processo específico de gestão de 


fornecedores. Por que será? Você já parou para pensar nisso? Se não parou, 


pare agora. 
2004 2005 2006 2007 
ITIL? V2 ITIL? V3 


FORNECEDORES 
VINCULADOS A 


FORNECEDORES 
GERENCIADOS COM UM 


CONTRATOS NO SLM PROCESSO ESPECÍFICO 


Imagine primeiro que este processo de gestão de fornecedores foi criado 
a partir do compêndio das melhores práticas já utilizadas no mercado em 
2006. Sim, porque em 2007 tivemos a publicação da ITIL® V3 e, se em 
2004 havia a publicação da ITIL® V2, então, na melhor das hipóteses, as 
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melhores práticas adotadas entre 2005 e 2006 foram compendiadas e exibi- 
das na V3 e agora reeditadas na versão 2011 (sem mudanças significativas). 
Isso nos faz pensar que, se já em 2006 o processo de gestão de fornecedo- 
res era tão importante (talvez lá fora), hoje, então, com a real viabilização 
do modelo “na nuvem” aqui no Brasil, ele está se tornando cada vez mais 
indispensável. 

Imaginar que podemos oferecer um serviço, estabelecer um compromisso 
com nossos clientes através de um acordo de nível de serviço e manter nossos 
clientes satisfeitos com os serviços recebidos sem ter o nosso relacionamento 
com nossos fornecedores pelo menos reformulado é apostar nossas fichas 
num “cavalo azarão”. Pode até dar certo, mas não é o que se espera. À pró- 
pria história da TTILº conta que o governo inglês procurou desenvolver uma 
biblioteca de melhores práticas não somente para seu uso próprio, mas tam- 
bém para orientar e padronizar o fornecimento de serviços por fornecedores 
externos. Logo, estamos falando de um conceito básico: o relacionamento 
com fornecedores externos de modo procedimental. 

Esta relação precisa ser reformulada bilateralmente. Não adianta a TI 
estabelecer processos de gerenciamento de fornecedores, criar contratos com 
eles e imaginar que tudo vai mudar se os próprios fornecedores não com- 
preenderem realmente o “idioma ITIL®” que estamos falando. O ideal seria 
que todos os nossos fornecedores tivessem uma certificação ISO-20.000, 
mas eles não têm. São capazes, muitas vezes, de oferecer um portfólio ex- 
tenso, um preço competitivo, benefícios etc., mas o comprometimento com 
a qualidade do serviço entregue através de um processo certificado pela 
ISO-20.000 não faz parte de suas ofertas, infelizmente. 

O próprio processo de qualificação de fornecedores estratégicos e táticos 
precisa levar em conta o grau de maturidade destes fornecedores com relação 
aos compromissos bilaterais assumidos. Todos sabemos que certos fornece- 
dores com os quais acabamos por estabelecer algum tipo de relacionamento 
para provimento de serviços externos não possuem a maturidade de que fa- 
lamos. E o que fazer então? Criar o plano B. 

Se o fornecedor que você está contratando não assegura um nível de 


serviço adequado e não concorda em renegociar os níveis oferecidos, então 
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você precisará de uma “cobertura complementar” para assegurar os níveis 
de serviço necessários. Por exemplo: você precisa de um tempo máximo 
de downtime de 10 minutos para seu link de comunicação, e seu fornece- 
dor não lhe garante um reparo em menos de 2 horas. Não há negociação 
possível? Adote o plano B. Busque a redundância com outro link. É um 
exemplo trivial, mas outras situações como esta podem estar mascaradas 
em prazos de entrega, áreas de cobertura, capacidade de atendimento, ga- 
rantias, custos etc. 

O que é importante destacar é que o gerenciamento de fornecedores não 
é mais uma tarefa isolada. Ele se transformou num processo e, portanto, 
tem um dono, políticas, regras, atividades, matriz RACI, entradas, saídas, 
realimentação, controles, métricas e tudo o mais que os demais processos 


possuem, ou seja: formalismo. 


Porém, não adianta imaginar que se sua empresa já possui uma área 
de compras e lá já existe um processo de qualificação, seleção, contra- 
tação e controle de fornecedores, tudo estará resolvido. Também não 
significa que o que é feito lá não nos seja aplicável. A ideia de que a área 
de compras possa complementar o processo que hoje já executa e servir 
de “responsável” (conceito da matriz RACI) para algumas das atividades 
propostas pelo processo de gestão de fornecedores na ITIL® é uma óti- 
ma alternativa. O processo que a área de compras executa é um processo 
genérico e, apesar de, em grande parte, poder ser útil para a TI, ainda 
precisa ser complementado para ser aderente aos requisitos da gestão de 


serviços de TI. 


PROCESSO DE GESTÃO DE 
FORNECEDORES CORPORATIVOS 


PROCESSO DE GESTÃO DE 


FORNECEDORES DE TI 


PTI? 


Lembre-se de que o novo relacionamento estabelecido com nossos 


fornecedores não é mais somente de uma relação comercial do tipo “eu 
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lhe pago e você me entrega”. O novo relacionamento estabelecido está ba- 
seado em compromissos de atendimento de SLA que precisam de OLA 
e de contratos externos, envolvendo, portanto, indicadores e métricas de 
entrega de serviços para permitir uma avaliação adequada do perfil do 
fornecedor. 


Uma revisão do processo de gestão de fornecedores será bastante útil e 
poderá lhe mostrar quais atividades, controles e métricas complementares a 
área de compras poderá absorver para cumprir seu papel corporativo, afinal: 
“A área de compras não estará trabalhando para a TI, está trabalhando para 


a organização”! 


LIÇÕES APRENDIDAS: O sucesso da entrega de serviços pela TI depende 
fortemente da cadeia de provedores de serviço que ela consiga estabelecer 
tanto internamente como externamente. Crie mecanismos para assegurar que 
estes relacionamentos sejam mapeados e controlados. Busque fornecedores 
externos que também utilizem critérios de gestão de serviços em seus relacio- 
namentos. 


QUE TIPO DE MUDANÇAS A TI PRECISA ESTAR PRONTA 
PARA ABSORVER? 


Outra afirmação de autor desconhecido, a quem atribuímos todos os cré- 
ditos onde quer que ele esteja, é: “No pain, no gain.” Esta expressão, criada 
originalmente no ambiente dos fisiculturistas e levada depois para os demais 
esportes e para a vida até mesmo dos sedentários, poderia passar a ser nosso 


“lema” de implantação da gestão de serviços de TI. 


NO PAIN, NO GAIN. 
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Todos queremos implantar as melhores práticas, novos processos e novos 
resultados, portanto devemos estar preparados para pagar o preço devido 
para a obtenção destes. Este preço, representado pelo “pain”, não deve ser 
traduzido como “sofrimento”, mas como um “esforço extra”. Não precisamos 
sofrer para ter resultados, mas precisamos de esforços extras, com certeza. 
Para fins didáticos, vamos nos limitar a cinco principais “esforços extras” 
que, normalmente, são necessários. São itens que podem ser observados em 
vários ambientes organizacionais, mas com certeza outros poderiam também 


ser citados e seriam igualmente importantes. 


Aumento de Maior Aumento de Aumento de 
conflito entre qualificação atividades atividades 
as áreas do pessoal operacionais gerenciais 


Maior 
formalismo 


1 - Maior formalismo 


Já falamos em produzir regras, em criar padronização e até em buscar 
meios para introduzir estas regras na organização. Isso parece muito acei- 
tável para a TI quando as regras que mencionamos são regras criadas pela 
TI para serem seguidas pelos clientes. Mas e quando as regras são para 
a própria TI? Que tipo de reação se espera? Várias e nem todas muito 
agradáveis, entre elas: resistência, descrédito, ceticismo, animosidade para 
alguns, e entusiasmo, apoio, receptividade e engajamento para outros. É 
claro que com os apoiadores da iniciativa não teremos maiores dificulda- 
des, mas, por outro lado, com os opositores, poderemos encontrar muitos 
empecilhos... 

A primeira dificuldade surge quando entre os opositores estão uma ou 
mais pessoas dos níveis gerenciais, e quanto maior o nível gerencial, maior a 
dificuldade. Já participamos de processos de implantação de gestão de servi- 
ços de TI em empresas nas quais, depois de os novos processos estarem defi- 
nidos, algumas pessoas dos níveis gerenciais literalmente afirmavam: “Estas 
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ideias são muito boas, mas aqui não vai funcionar, pois a empresa é muito 
resistente a mudanças.” 

Se por um lado eles diziam isso, por outro nós claramente ouvíamos: “Es- 
tas ideias são muito boas, mas não vou arriscar implementá-las aqui, pois eu 
sou resistente a mudanças.” Numa dessas experiências foi que compreen- 
demos que os conceitos da ITIL® não podiam ser repassados somente aos 
níveis operacionais e que o engajamento devia ser buscado desde o início 
nos diversos níveis envolvidos. Esperamos que a lição aprendida possa ser 
repassada. 

A resistência, porém, não ocorre só no nível gerencial, podendo ser até 
mais frequentemente percebida no nível operacional. Muitas vezes, não é 
uma resistência explícita. Existem aquelas pessoas que dizem “para mim tan- 
to faz” ou “não tenho nada para acrescentar” ou “se vocês definiram assim, 
então está ótimo” e até “o trabalho que vocês estão fazendo está excelente”. 
Muitas vezes uma concordância sem senso crítico, sem análise detida, revela 
um descaso com o assunto, o que também é uma forma de resistência. Os 
motivos para a resistência podem variar conforme o perfil das empresas, seu 
tamanho, o grau de maturidade, entre outros fatores. 

Não podemos definir uma regra de comportamento, mas, normalmen- 
te, as empresas privadas com gestão profissionalizada, onde critérios de 
governança corporativa já estão estabelecidos, têm maior facilidade para 
absorver tais mudanças. Não que não existam empresas públicas bastante 
adiantadas em aspectos de gestão de serviços de TI ou que empresas com 
gestão familiar não possam ter também já implantado com sucesso este 
tipo de iniciativa. Existem relatos de projetos em tais ambientes e também 
com bons resultados. 

Independentemente do ambiente onde seja detectada a resistência, é im- 
portante que se tenha em mente que isso é parte integrante do processo de 
mudança. O lema “no pain, no gain” vale aqui também. Não é só a equipe de 
TI que terá que passar por algum tipo de esforço extra para obter resultados, 
mas também aqueles que estejam implantando o processo de gestão de servi- 
ços de TI (o “grupo da ITIL®”) deverão dar sua cota de esforço extra. Supe- 


rar estas resistências é o esforço extra esperado de você. Prepare-se desde já. 
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Como já dissemos anteriormente, procure se colocar no papel das pessoas que 
deverão absorver as mudanças na TI, veja quais são os fatores de motivação que 
você poderia usar e quais são os fatores de restrição também. Busque apoio dos 
níveis gerenciais. Faça o endomarketing de seu projeto. Lembre-se sempre de 
apresentar os benefícios que os outros terão no processo, e não os benefícios que 
você obterá. Ninguém fará nada diferente se não tiver benefícios próprios. 

Quando falamos em formalismo, a própria palavra pode produzir a reação 
de resistência. Talvez outros termos possam ser utilizados para representar a 
mesma necessidade. Não queremos necessariamente o formalismo, queremos 
somente ter o estabelecimento de regras, a criação de padrões, a definição de 
modelos, o registro e documentação de tudo o que é feito, a rastreabilidade 
das ações e a definição de papéis e responsabilidades nos processos. Simples, 
não? Se, para você, um termo melhor do que “formalismo” surgir em sua 


mente ao ler todos estes requisitos, use-o. 


FORMALISMO 


REGRAS MODELOS REGISTROS 


PADRÕES RASTREABILIDADE PAPÉIS 


Qualidade exige previsibilidade de resultados e rastreabilidade para acompa- 


nhamento de não conformidades. Infelizmente não há outro meio de se obter 
qualidade sem formalização. Se você parar para observar, a ITIL® recomenda 
em diversos pontos de suas melhores práticas a adoção de formalizações: mo- 
delos de incidente, modelos de mudanças, modelos de problemas, modelos de 
liberação, processos padronizados, registros para produção de métricas prede- 
finidos, regras de SLA, políticas, matrizes RACI, ciclos de PDCA, e por aí 
vai. Imaginar que será possível implantar alguma melhor prática que não passe 
por uma abordagem focada em formalismo é pura ilusão. Qualquer programa 
de qualidade envolve formalismo no planejamento, execução, monitoramento, 
e até na proposta de melhorias de atividades. Se a organização busca melhorias 
terá que assumir este esforço extra. 
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LIÇÕES APRENDIDAS: Ao promover mudanças no ambiente operacional e geren- 
cial da TI iremos com certeza enfrentar resistências. Fique atento à resistência 
explícita e também à não explicita. Esta segunda é ainda mais perigosa do que a 
primeira. Dê também a sua cota de “esforço extra” para enfrentar as resistências 
encontradas. Lembre-se: “No pain, no gain.” 


2 - Aumento de conflito entre as áreas 


Vamos considerar um cenário no qual já tenhamos implantado novos 
processos, tenhamos a rastreabilidade de atividades desenvolvidas, seja pos- 
sível monitorar e produzir indicadores e que envolva diversas áreas da orga- 
nização, entre elas a própria TI e também fornecedores externos. O que seria 
esperado que acontecesse? 

Primeiro que a rastreabilidade de atividades fosse vista por muitos não 
como uma ferramenta de gestão, mas como um meio para “encontrar os 
culpados”. Também a monitoração e a produção de indicadores poderia ser 
vista mais como meio de provar que algo está errado do que como forma de 
provar que tudo está bem. É como informar para uma área que uma audito- 
ria qualquer será realizada. À figura do auditor será rapidamente associada 
à pessoa que vem para procurar falhas, quando na verdade deveria ser asso- 
ciada à pessoa que vem para nos certificar de que estamos fazendo tudo de 
acordo com a norma. 

Se este sentimento de “busca dos culpados” não for revertido em curto 
prazo teremos criado então um ambiente propício ao desenvolvimento de 
conflitos entre as áreas e, às vezes, até entre as pessoas. Às áreas e pessoas 
estarão muito mais preocupadas em justificar seus eventuais erros e não con- 
formidades, ou pior, em transferi-los para outras áreas, do que em estabele- 


cer contramedidas para saná-los. 


ENFOQUE TRADICIONAL ENFOQUE GESTÃO DE SERVIÇOS DE TI 


FALHAS = BUSCA DOS CULPADOS FALHAS = MELHORIA CONTÍNUA 
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Precisamos sempre manter em destaque para todos os envolvidos que o 
processo de implantação da gestão de serviços de TI baseado na ITIL® tem 
um princípio essencial que não pode ser relevado: a melhoria contínua do 
ciclo de vida dos serviços. As pessoas precisam entender, e assumir, que se 
existe melhoria contínua é porque existe descoberta contínua de pontos a 
melhorar, ou seja, descoberta de falhas ou não conformidades que podem 
ser sanadas. Se esta visão for corretamente transmitida a todo o grupo o 
foco dado a este processo passará de “quem produziu a falha ou não confor- 
midade?” para “como poderemos atuar sobre este ponto detectado?”. 

Outro fator gerador de conflitos que pode ser detectado e que precisará 
ser contornado é o fato de que, com a formalização dos processos, os papéis 
e responsabilidades atribuídos às áreas se tornam mais evidentes e, portan- 
to, a cobrança por resultados será mais direta. Se cobranças começarem a 
ser feitas da área A para a área B, que, por sua vez, cobra da área C, que, 
por sua vez, transfere a responsabilidade para a área À, então a chance de 
conflitos é grande. 

Novamente é importante que a visão de resultados seja concentrada em 
processos e não em áreas. Se um processo não produz os resultados adequa- 
dos nos tempos adequados, então as falhas não são da área A ou da área B. 
As falhas são do processo como um todo e as cobranças devem ser transfe- 
ridas para o dono do processo e não para os executores. Lembre-se de que o 
processo de melhoria contínua também deve atuar sobre os processos. Mais 
uma vez, estamos falando de oportunidade de melhoria e não de queixas por 


deficiências. Este é mais um conceito a ser absorvido e praticado! 


LIÇÕES APRENDIDAS: Ao propor novos processos, procure demonstrar mais os 
benefícios do novo processo do que as deficiências do antigo. Destacar as de- 
ficiências pode gerar um sentimento equivocado de que existem culpados pelos 
erros. Defina melhorias e indique quem poderão ser os responsáveis por im- 
plementá-las. Estas pessoas automaticamente passarão a estar comprometidas 
não com a correção de deficiências, mas sim com a implantação de melhorias. 
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3 - Maior qualificação do pessoal 

O trabalho em ambientes colaborativos, focados em resultados, exige um 
maior grau de maturidade e comprometimento das equipes. A qualificação a 
que estamos nos referindo não é só a qualificação técnica, que também deverá 
haver, mas a qualificação nos demais aspectos. Era senso comum, há alguns 
anos, o fato de que para compor uma excelente equipe de atendimento e su- 
porte deveríamos buscar os especialistas mais qualificados em cada uma das 
tecnologias aplicadas no ambiente. Criavam-se então equipes cheias de “nerds” 
incomunicáveis que isoladamente eram excelentes para produzir resultados, 
mas que, quando colocados para trabalhar em equipe, produziam quase nada 
além de conflitos. Com o passar do tempo e com a interconexão de tecnologias 
e ambientes, ficou cada vez mais difícil encontrar um tipo de incidente ou de 
problema que pudesse ser resolvido isoladamente pelo “nerd incomunicável lá 
da mesa do fundo”. Como alocá-lo junto a outro “nerd incomunicável” seria 
uma “receita explosiva”, os gestores tiveram que começar a investir na busca de 
novas peças para seus quebra-cabeças. Cada peça pode ser única, mas deve se 
encaixar perfeitamente com as demais para gerar um resultado efetivo. 

Esta maior qualificação das equipes, não só com conhecimentos técni- 
cos, mas com conhecimentos de relacionamento, de trabalho em grupo, de 
colaboração, de troca de conhecimentos, entre outros, deve ser incentivada, 
desenvolvida internamente ou buscada externamente. Aqueles que não con- 
sigam conviver dentro destas novas regras estarão fadados ao esquecimento. 
É verdade que com o advento das redes sociais, dos blogs, das comunidades, 
dos fóruns etc., é cada vez mais fácil encontrar pessoas dispostas a comparti- 
lhar seus conhecimentos, discutir suas verdades, colaborar. São especialistas 
que compartilham e buscam novos conhecimentos transformando-se assim 
também em generalistas em outros assuntos correlatos, além de desenvolve- 


rem suas capacidades de relacionamento. 


ENFOQUE TRADICIONAL ENFOQUE GESTÃO DE SERVIÇOS DE TI 


CONHECIMENTO TÉCNICO RELACIONAMENTO 


TRABALHO INDIVIDUAL TRABALHO EM GRUPO 
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Incentivar este tipo de troca de experiências dentro e fora do ambiente 
onde a gestão de serviços de TI esteja sendo implantada pode servir como 
facilitador na integração destas pessoas a diversos processos nos quais atuem, 
tanto como protagonistas quanto coadjuvantes. Se a iniciativa da troca de 
experiências e de conhecimento não surgir naturalmente no ambiente, deve- 
remos propiciar meios para que ela se estabeleça, pois os próprios processos 
de gestão de conhecimento e de gestão de problemas precisarão de pessoas 
com este perfil. Tanto as equipes quanto os gestores das equipes precisam se 
preparar para acabar com os “feudos” que possam existir nas diversas áreas 
envolvidas. 


LIÇÕES APRENDIDAS: Procure desenvolver de modo equilibrado novas compe- 
tências técnicas e de relacionamento entre os envolvidos. A ITIL® exige maior 
grau de relacionamento e compartilhamento de atividades e responsabilidades 
entre as áreas do que as abordagens convencionais. A visão de processos que a 
ITIL® estabelece requer principalmente cooperação, visando os resultados para 
o processo e não os resultados para as áreas. Pessoas e áreas devem ser vistos 
como agentes em processos que podem, ao final, beneficiar inclusive outras 


áreas. Quem ganha com isso é a organização. 


4 - Aumento de atividades operacionais 


É sabido que podemos obter muitas melhorias com a adoção de melhores 
práticas para a gestão de serviços de TI. Mas será que vamos conseguir isso 
sem o aumento de atividades operacionais? Será que tendo o mesmo rol de 
atividades hoje já executadas vamos conseguir agregar melhorias? Querer 
obter tantos benefícios sem agregar novos recursos ou atividades não contra- 
riaria a regra de “no pain, no gain”? Pense bem. 

Queremos maior controle, logo teremos de ter atividades de registro, me- 
dição, tabulação, interpretação e proposta de ações. Queremos um processo 
de atendimento mais efetivo, logo teremos que gerenciar um catálogo de 
serviços, estabelecer SLA, construir um CMDB. O que lhe parece? Não fica 
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evidente que para obter novas saídas precisamos também de novas entradas? 
Ou, pelo menos, de novas transformações das entradas que já temos? Não sei 
se isso chega a ser uma má notícia para muitos ou se é simplesmente um fato 


já detectado que muitos temem encarar: teremos novas tarefas a executar! 


ELEMENTOS QUE PODEM SER ALTERADOS 


ENTRADAS + PROCESSOS D) 


Você pode então estar pensando: “Como é que a TI vai conseguir absorver 
novas atividades se hoje já está com a equipe saturada?” À resposta pode não 
parecer muito boa, mas é a pura verdade: “Agregando mais recursos à equipe 
atual.” Esta ideia pode parecer um absurdo para muitos gestores e com certe- 
za será mais uma das resistências que teremos que vencer. Prepare-se. 

Vamos voltar às analogias para exemplificar o que acontece em outros 
setores. Imagine que muito tempo atrás em uma empresa X não existisse 
um processo de gestão de recursos humanos muito aperfeiçoado. As pes- 
soas, para serem contratadas, traziam seus documentos, apresentavam à área 
de RH, que os arquivavam, anotações eram feitas na carteira de trabalho, 
orientações dadas e, em pouco tempo, estavam contratadas. Tudo isso podia 
ser feito por uma só pessoa na equipe de RH. Aí então esta empresa resolve 
implantar um processo de gestão de recursos humanos melhor. 

A empresa busca um processo com o qual possa controlar mais efetiva- 
mente sua força de trabalho, obter indicadores, monitorar o desenvolvimen- 
to de seus recursos humanos, controlar as informações sobre os funcionários 
e compartilhar estas informações entre o corpo gerencial. Para atingir este 
objetivo, implanta então um processo de gestão de recrutamento e seleção, 
um processo de gestão de desenvolvimento de RH e de manutenção de da- 
dos cadastrais. A partir deste dia, não basta mais receber os documentos 
dos funcionários e guardá-los numa pasta. É preciso transcrever todos estes 
dados em formatos específicos em telas e campos de um sistema de entrada 
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de dados. Todos os treinamentos feitos pelo funcionário precisam, além de 
ter seus certificados gerados, ser também cadastrados numa base de dados 
para consulta futura, dados de dependentes, dados de formação acadêmica, e 
tantos outros que têm de ser cadastrados e constantemente atualizados num 
sistema informatizado. 

Há de se imaginar que aquela única pessoa antes existente não seja mais 
suficiente para absorver todas estas novas atividades que produzirão todos 
os novos benefícios, concorda? E não é isso o que ocorre nas empresas 
em suas áreas de RH, de contabilidade, de produção? Todas as áreas de 
gestão que se desenvolvem agregam novas atividades e, por conseguinte, 
novas pessoas para cobrir estas atividades extras. Não poderia ser diferente 
na TI. 

O que devemos estar preparados é para justificar os benefícios de se exe- 
cutarem novas atividades (método do bem) ou mostrar as restrições que serão 
impostas se estas atividades não forem executadas (método do mal). Muitas 
vezes ouvimos pessoas dizerem que a implantação da gestão de serviços de 
TI criou uma demanda por mais recursos. Precisamos discordar deste pensa- 
mento! O que a gestão de serviços de TI fez foi demonstrar a ausência de re- 
cursos necessários que antes não estavam presentes no ambiente. Não foi ela 
quem gerou a demanda. A demanda sempre existiu, mas não era atendida. 
Agora, simplesmente, através de um processo formal pudemos demonstrar 
que havia um subdimensionamento de recursos e que isso estava levando à 
entrega de serviços que não atendiam aos requisitos impostos pelos próprios 
clientes. Lembre-se: “Qualquer fornecedor que tenha uma equipe subdi- 
mensionada não vai conseguir prover os serviços com a qualidade esperada 
por seus clientes.” Isso é fato! Se há subdimensionamento, um aumento de 
equipe não é uma expansão, mas sim uma reposição! 

Mesmo com todos estes fatos e argumentos, continuaremos a encon- 
trar gerentes que simplesmente dirão: não podemos agregar mais recursos 
à equipe. Só resta então avaliarmos se há alguma ociosidade que justifique a 
absorção de novas tarefas sem expansão da equipe, ou então, infelizmente, 
assumirmos que realmente não haverá como agregar os benefícios esperados 


sem um esforço extra da equipe atual. Lembre-se: o que para muitos é custo 
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extra, para outros é investimento adicional. O que vai diferenciar um de ou- 
tro é a visão do resultado obtido. 

O que pode ser visto como custo para a TI também pode ser enxergado 
como um investimento para o alcance dos objetivos da organização. Ativida- 
des extras que terão de ser executadas pela TI podem garantir, por exemplo, 
que um serviço provido tenha maior disponibilidade e capacidade fazendo 
com que a empresa gere negócios mais rapidamente, que tenha seus clientes 
mais bem atendidos, que reduza custos de operação e produção, e assim por 
diante. Não se trata de quanto se gasta, mas de por que se gasta e para que 
se gasta. Saber justificar tais questões talvez seja o maior desafio. Este é mais 
um ponto que demonstra a necessidade de o nível gerencial também se en- 
gajar nas iniciativas da GSTI. 


LIÇÕES APRENDIDAS: Para obter melhores resultados provavelmente teremos de 
implantar novos processos e novas atividades em processos já existentes. Isso 
irá demandar recursos no curto, médio e longo prazos. Não é a ITIL® que exige 
novos recursos. Ela só demonstra que eles já deveriam estar alocados, mas que 


estavam ausentes. 


5 - Aumento de atividades gerenciais 


Falar em aumento de atividades operacionais implica falar também no 
aumento de atividades gerenciais. Seja pelo aumento das equipes, de ativida- 
des operacionais, de complexidade e completeza dos processos, de controles 
ou por outras razões já descritas, há de se esperar um papel mais ativo dos 
gerentes. 

Seja no aspecto quantitativo ou qualitativo, a atuação dos níveis gerenciais 
será mais exigida. A habilidade de negociar recursos (inclusive o aumento de 
equipes, como vimos), motivar as equipes, estabelecer métricas, implantar 
iniciativas focadas em resultados, justificar níveis de serviços e tantas outras 


competências serão exigidas neste novo cenário. Não haverá mais lugar para 
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aqueles que se limitam a soluções ortodoxas e que insistem em ignorar as 
oportunidades de melhoria contínua. 

Muitos podem novamente ver um foco de resistência neste ponto. La- 
mento dizer que estão certos. Lamento, pois realmente este foco de resis- 
tência existe e, muitas vezes, é difícil de ser removido por completo. Em 
algumas organizações encontraremos maior inércia do que em outras. Em 
certas pessoas encontraremos maior inércia do que em outras. Concentre-se 
sempre em demonstrar não “o que” deverá ser feito a mais pelos níveis geren- 
ciais, mas “por que” e “para que” deverá ser feito. 

O foco nos resultados poderá ser um fator que motive alguém a mudar seu 
estado de inércia. Se hoje algo é feito de um modo e assim se mantiver, não 
teremos resultados diferentes. Se resultados diferentes não forem obtidos, o 
próprio desempenho gerencial poderá ser questionado, pois a organização 
pode já estar insatisfeita com os serviços providos pela TI e aguardando mu- 
danças. Esta visão poderá fazer algumas pessoas entenderem que a mudança 
no modo de atuação gerencial não é uma questão de escolha, mas é uma 
questão de diferencial. 


LIÇÕES APRENDIDAS: Implantar a GSTI implica necessariamente reforçar os as- 
pectos de gestão. Resistências a esta característica podem ser encontradas prin- 
cipalmente em ambientes em que o gestor já tem grande envolvimento nas ativida- 
des operacionais, intencionalmente ou não. Procure demonstrar que as mudanças 


não são uma opção, mas uma necessidade. 


QUE ESTRATÉGIAS A TI DEVE ADOTAR PARA FACILITAR 
A IMPLANTAÇÃO DA GSTI? 


Algumas iniciativas e estratégias já vêm sendo citadas em forma de re- 
comendações e lições aprendidas ao logo dos temas que já exploramos e 
continuarão a ser apresentadas nos próximos capítulos. Algumas estratégias, 
entretanto, se aplicam a todos os temas que serão discorridos no livro e serão 


apresentadas a seguir. 
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Desenvolver uma visão orientada para processos 
Identificar atividades e recursos 


Estratégias para 


facilitar a Mudar paradigmas 
implantação da 
GSTI 


Fazer o marketing da GSTI 


Desenvolver uma visão orientada a processos 


Parece desnecessário falar em processos quando toda a ITILº é focada 
em processos, mas lembre-se: estamos falando de desenvolver esta visão não 
só naqueles que fizeram o curso de TTILº Foundation, mas em todos os en- 
volvidos na TI (e até fora dela). Esta estratégia reforça muitas das recomen- 
dações e lições já citadas até aqui. Veja, por exemplo, a questão da resistência 
em absorver novas atividades ou a aumentar o quadro de pessoal. Trata-se 
de dois pontos que podem ser contornados se, antes de discutirmos se vai ou 
não haver alguma atividade adicional ou se vamos ou não precisar de recursos 
extras na nossa equipe, tivermos uma discussão sobre quais processos devem 
ser executados, sobre suas finalidades, entradas e saídas que eles requerem e 
produzem e benefícios que agregam. Se pudermos comprovar a necessidade 
de um dado processo ou identificar uma relação custo-benefício que seja 
justificável, poderemos então somente em um segundo instante apresentar 
os recursos que ele demanda e o modus-operandi que ele requer. Manteremos 
o foco nos resultados do processo antes de colocar o foco nos recursos neces- 
sários a ele. 

Esta visão orientada a processos reforça os aspectos de padronização, de- 
finição de papéis, repasse de conhecimento, criação de pontos de controle 
e de geração de métricas. Aqueles que já tiveram a oportunidade de tam- 


bém fazer o treinamento de Cobit Foundations? e tiveram acesso aos temas 
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relacionados à governança de TI vão também lembrar que uma das caracte- 
rísticas gerais colocadas como essenciais para um bom framework de controle 
é “ser orientado para processos”. Isso também reforça nosso ponto de vista 
de que desenvolver uma visão orientada a processos pode ser um grande faci- 
litador na questão da gestão de serviços de TI. Se não fosse assim, então por 
que todo o material da ITIL® estaria segmentado em processos? 

Um erro que frequentemente presenciamos em empresas na hora de de- 
finir o escopo para implantação da gestão de serviços de TI é procurar usar 
esta visão de processos para tentar isolá-los. Algumas empresas estabelecem 
como meta, por exemplo, “implantar só o processo de gestão de incidentes”. 
Imaginam, então, que vão implantar um service desk e que este irá operar so- 
mente com o processo de gestão de incidentes, como se isto fosse possível. 

Pense: como iremos realmente gerenciar incidentes de serviços de TI se 
não temos sequer um catálogo de serviços? E o que faremos com as solici- 
tações que chegarão ao service desk e que não são incidentes? Ainda na V2, 
o processo de gestão de incidentes abrangia, de certo modo, as requisições 
de serviços e eventos. Agora na V3, em que cada um destes processos é um 
processo separado, me parece que não há como deixar de tratá-los de modo 
integrado. E as solicitações de mudança? Vão ser tratadas como incidentes? 
Vão ser ignoradas? 

Temos que pensar melhor sobre a ideia de implantar somente um pro- 
cesso. Voltando somente ao exemplo da necessidade do catálogo de serviços, 
muitas pessoas dizem que criarão um catálogo, mas que não precisarão de um 
processo para mantê-lo. Será? De que adiantará criar um catálogo de serviços 
sem um processo mínimo de manutenção? Teremos um catálogo válido por 
quanto tempo? Um mês, seis meses? E que utilidade realmente ele terá se 
não tivermos neste catálogo nada além do nome dos serviços? Sim, porque 
o que algumas empresas chamam de um catálogo de serviços é na verdade 
uma lista de nomes de serviços (será que a V4 trará o conceito diretório de 
serviços?) que, mesmo com toda a boa vontade e esforço de alguns, acabará 
desatualizada em pouco tempo. 
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A questão da interoperabilidade de processos é ainda mais complexa se 
pensarmos que muitas empresas querem simplificar seus escopos e acabam 
se focando excessivamente na criação de um service desk e na implantação 
dos processos do ciclo de vida de operação dos serviços e, quando muito, em 
alguns processos da transição. Isso faz com que processos do nível estraté- 
gico e do desenho fiquem “para quando der tempo”. É assim que o catálogo 
de serviços e os SLA viram “agregados informais” do processo de operação. 
Muita gente desavisada será capaz de “jurar” que um SLA é um elemento da 
gestão de incidente e que deve ser definido pelo coordenador do service desk. 
Vamos estudar a questão nos próximos capítulos. 

Uma boa estratégia para abordar este tema poderia ser: defina, sim, uma 
visão focada em processos. Defina os processos essenciais para a operação do 
seu service desk, mas não só os da fase de operação dos serviços. Concentre- 
se e aprofunde-se em alguns processos mais diretamente ligados ao servi- 
ce desk, tais como o de incidentes, cumprimento de requisições, eventos, 
mudanças etc. Trate com menor profundidade (mas não deixe de fora!) os 
processos complementares que criam e mantêm objetos importantes de uso 
do service desk. Nos próximos capítulos vamos focar em quatro processos 
importantes na geração destes artefatos de apoio. Veremos os processos de 
gestão de configuração, gestão de catálogo de serviço, gestão de nível de ser- 
viço, e gestão do conhecimento, bem como os importantes artefatos que eles 


produzem e mantêm. 


LIÇÕES APRENDIDAS: Focar-se em processos é uma iniciativa essencial, mas 
mantenha sempre uma visão integrada. Pense nas entradas e saídas que o(s) 
processo(s) escolhido(s) requer(em) e descubra as interligações que não podem 
deixar de ser tratadas. Tenha em mente os artefatos essenciais que os processos 
de operação de serviços requerem, e implemente, ao menos, processos básicos 
que produzam e mantenham estes artefatos. 
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Identificar atividades e recursos 


Um dos primeiros levantamentos que deveriam ser feitos na fase inicial 
da implantação da gestão de serviços de TI é o levantamento das atividades 
executadas pelas equipes e dos recursos existentes. Estes têm duas finalida- 
des: reconhecer aquilo que já é feito de bom e o potencial que temos para 
complementar aquilo que ainda não é feito. Muitas empresas se surpreen- 
dem quando, após um levantamento inicial, descobrem que já aplicam mui- 
tas das melhores práticas de gestão de incidentes mesmo sem saber. Outras 
descobrem que já têm muitas fontes de informação preciosas para criar seu 
catálogo de serviços ou para alimentar seu CMDB. 

É verdade que também podemos descobrir que não temos tanta aderência 
ou recursos disponíveis assim. Em ambos os casos, tendo um gap grande ou 
pequeno, é importante que ele seja conhecido. Se for pequeno, conseguire- 
mos uma maior motivação dos envolvidos no projeto, pois os objetivos a se- 
rem traçados parecerão não estar assim tão longe. Se for grande, a motivação 
poderá não ser tanta, mas, pelo menos, não criaremos expectativas falsas e 
não frustraremos pessoas ao longo do caminho. 

Estes levantamentos podem se utilizar de diversas técnicas, entre elas: 
análise de documentação existente, entrevistas, consultas, análise de ba- 
ses de dados e observação presencial. Devem seguir um roteiro conhecido 
previamente pelos envolvidos e planejado com antecedência. Como diz o 
ditado: “Quem não sabe o que procura, nunca sabe quando já encontrou.” 
Se você, no papel de implantador da gestão de serviços de TI, estiver con- 
duzindo o processo de levantamento, deverá então criar uma lista de todos 
os itens que julga necessários para estruturar o service desk (o menor esco- 
po possível, ou melhor, aquele que as empresas normalmente solicitam que 
seja atendido) e depois listar as possíveis fontes de informação onde poderá 
obtê-los. Com isso, você poderá criar uma matriz entre itens e fontes de 
modo a poder mais rapidamente inspecionar uma única fonte e coletar 


todos os itens possíveis. 
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LIÇÕES APRENDIDAS: Conhecer os recursos que você dispõe pode ser a maneira 
mais fácil para transformá-los em fontes de novos recursos, seja pelo aproveita- 


mento, transformação ou complementação. 


Mudar paradigmas 


Este talvez seja um dos pontos mais importantes de todo o nosso processo 
de implantação da GSTI. Todo o treinamento técnico, todo o empenho, 
todo o engajamento, todo o apoio financeiro e toda a sua competência em 
conduzir o processo podem não ser suficientes se o ponto de vista das pessoas 
não for mudado. 

Vamos usar aqui uma analogia: imagine que você é um estudante de pin- 
tura artística e foi chamado para uma aula em que todos os alunos se sentarão 
em círculo ao redor de um modelo vivo que ficará no centro da sala. Cada 
um, de seu lugar, deverá pintar aquilo que vê à sua frente. Ao final da aula, 
os desenhos serão coletados e comparados. O resultado será surpreendente. 
Aquele aluno que sentou de frente para o modelo irá desenhá-lo com muitos 
detalhes da face, mas poucos detalhes do cabelo e das costas. Já aquele aluno 
que se sentou virado para as costas do modelo irá desenhá-lo com muitos 
detalhes do cabelo, porém nada, ou muito pouco, se saberá sobre sua face. 
Cada representação será diferente das demais apesar de todas elas serem ba- 
seadas no mesmo modelo. Nenhuma delas estará errada, apesar de poderem 
ser muito diferentes umas das outras. 

Esta analogia nos mostra que se as pessoas que estiverem participando 
do projeto de implantação da GSTI “não saírem de seus lugares” e “não se 
permitirem ver o mesmo ambiente por outro ponto de vista”, elas serão como 
aquele aluno que, por sempre ter se sentado de frente para o modelo, nunca 


vai acreditar que ele tem uma tatuagem nas costas. 
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Muitas pessoas insistem em dizer que a organização não está preparada 
para as mudanças que desejaremos implantar simplesmente porque nunca 
saíram de suas posições atuais para procurar ver a mesma organização que 
eles julgam intocável por outro ponto de vista. A inércia que impede o aluno 
de trocar de cadeira para poder ver que o modelo tem realmente uma tatua- 
gem é a mesma inércia de muitos técnicos e gestores que dizem que se algo 
sempre foi feito de certo modo, não será possível mudar, pois as pessoas não 
vão aceitar. Estas pessoas, pelo seu ponto de vista atual, veem a organização 
de um modo que realmente tornaria impeditiva qualquer mudança. Porém, 
ao se permitirem observar a organização por um novo ponto de vista, talvez 
passem a acreditar que as mudanças são, sim, possíveis. A gestão de serviços 
de TI exige que cada um “mude de cadeira” para poder ver a organização e o 
papel da TI sob um novo ponto de vista. 


LIÇÕES APRENDIDAS: Pessoas que não se permitem observar um mesmo cenário 
de outra perspectiva nunca terão a oportunidade de descobrir novos recursos 
neste mesmo cenário. Muitas vezes, a impossibilidade de realizar uma mudança 
só continuará a existir se você não mudar o modo como o problema é apresentado 


e tratado. 
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Realizar o marketing da GSTI 


Segundo o site Wikipédia, marketing é “o processo usado para determinar 
que produtos ou serviços poderão interessar aos consumidores, assim como a 
estratégia que se irá utilizar nas vendas, comunicações e no desenvolvimento 
do negócio. A finalidade do marketing é criar valor e satisfação no cliente, 
gerindo relacionamentos lucrativos para ambas as partes”. 

Portanto, parafraseando a definição acima, fazer o marketing da gestão 
de serviços de TI é determinar se e como a GSTI poderá interessar à TI e à 
organização, assim como determinar as estratégias para “vender esta ideia”, 
manter uma comunicação efetiva com os clientes da GSTI e fazer a GSTI se 
desenvolver dentro da organização, criando benefícios para a organização e 
gerando satisfação entre os envolvidos, mantendo sempre um relacionamen- 
to que seja bom para ambas as partes. 

Conclui-se com isso que a implantação da GSTI não pode ser feita por 
imposição ou por determinação, mas sim que deve ser parte de um processo 
de marketing que crie demanda, posicione a oferta, estabeleça custos, agre- 
gue valores e mantenha a fidelização dos clientes. Não por acaso a ITILº 
denomina clientes aqueles a quem a TI entrega seus serviços. Coincidência? 
Não, conceito do marketing. 


PRODUTO PRAÇA PROMOÇÃO 


GSTI Organização Estratégias 


Como todo bom plano de marketing, precisamos definir e atuar sobre 
os 4Ps do marketing: produto, praça, preço e promoção. Teremos de ca- 
racterizar muito bem o “produto” que iremos oferecer, qual será a nossa 
“praça”, que “preço” as pessoas deverão pagar para tê-lo e como realiza- 
remos “promoções” para captar clientes do produto. Nosso produto é a 
GSTI. Nossa praça é nossa organização ou partes dela. Nosso preço são as 
condições e regras que teremos que estabelecer para os clientes seguirem. 
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Nossa promoção são as estratégias que usaremos para conquistar nossos 
clientes. Explorar cada um destes itens pode significar ter ou não sucesso 


na implantação da GSTI. 


LIÇÕES APRENDIDAS: Qualquer projeto ou iniciativa que tenha que ser inserida no 
ambiente organizacional requer uma abordagem que respeite os 4Ps do marketing. 
Se você não conseguir definir um bom Plano de Marketing para a GSTI é porque 
você ainda não está preparado para “vender este produto”. 


Inovar 


Aplicar a TTILº como base para a implantação da GSTI é considerado 
por muitos uma inovação. Mas será que realmente aplicar um conjunto de 
melhores práticas publicadas em 2007 poderia ser chamado de inovação em 
nossos dias? 

Sob este ponto de vista também inovador, poderíamos sugerir que aque- 
les que vão implantar a GSTI usem sim a ITIL® V3 como base, mas que se 
permitam inovar ajustando ou criando suas novas melhores práticas. E no 
que se baseia esta recomendação? É simples: na experiência pessoal. Assim 
como muitas pessoas, tivemos nosso primeiro contato com a ITIL® V2 ain- 
da em 2004. Após certo tempo de estudo, concluímos que aquele paradigma 
realmente tinha muito a acrescentar para a melhoria do Service Support e 
Service Delivery. Nós, como tantos outros que se iniciaram pela V2, ficamos 
entusiasmados quando se anunciou, somente três anos depois, que teríamos 
uma V3. Para nós e para muitos, o entusiasmo se transformou em surpresa. 
O conceito do ciclo de vida do serviço que a V3 trouxe fez com que todos 
se perguntassem: “Mas como é que eu nunca tinha pensado nisto? Isto é tão 
claro! Como é que na V2 não tínhamos visto o assunto sob este ponto de 
vista?” Porém, os principais processos foram todos mantidos sem maiores 


alterações. 
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E essa experiência, que quem migrou da V2 para V3 teve, que nos faz 
pensar que precisamos ser inovadores e começar, hoje mesmo, a produzir a 
V4. Se de 2004 em diante, todos tivessem somente se restringido a aplicar 
os conceitos da V2, onde estaríamos hoje? Usando a V2. Ciclo de vida do 
serviço? Quem saberia o que é? Isso significa que, se nos próximos dias, me- 
ses e anos continuarmos a nos restringir somente aos conceitos da V3, não 
evoluiremos rumo a V4. Nunca teremos um processo de “Gestão de Equi- 
pes” como já sugerimos anteriormente. Nunca deixaremos de acreditar que, 
para definir a prioridade de um chamado, basta combinar o impacto com a 
urgência (conceito que precisa ser revisto com maior profundidade em uma 


próxima versão). 


ITIL® V3 


Edição 2011 


Essas e outras questões até mais básicas, inclusive algumas operacionais, 
precisam continuar a ser contornadas, tratadas de modo ligeiramente dife- 
rente daquilo que a V3 categoricamente sugere, sem, no entanto, ferir os 
princípios e a linha-mestre da GSTI. Isso também aconteceu quando os 
inovadores criaram a V3. Muita coisa foi agregada, melhorada, refinada, mas 
incidente continuou sendo incidente e problema continuou sendo problema. 
Tudo no seu devido lugar. 

Para inovar não precisamos revogar as verdades, mas devemos questioná- 
las. Precisamos ser críticos sem a intenção de encontrar defeitos, mas bus- 
cando a melhoria contínua, afinal, não é este um princípio sugerido na pró- 
pria ITIL®: planejar, fazer, verificar, ajustar? Pode-se aplicar esse princípio 
do aspecto micro ao macro, dos indicadores aos processos, dos conceitos à 
estrutura da própria ITILº. Será que o conceito de ciclo de vida do serviço 
que hoje parece ser tão intocável resistirá à inovação daqueles que, além de 
o absorverem, também se reservam o direito de questioná-lo? É com este 


ponto de vista que iremos trabalhar nos próximos capítulos. 
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LIÇÕES APRENDIDAS: Quando fazemos tudo sempre igual, obtemos sempre os 
mesmos resultados. Isso pode ser ótimo sob o ponto de vista da repetitividade e 
da garantia da qualidade do resultado. Por outro lado, a ITIL® está baseada no 
conceito de melhorias contínuas e isso exige capacidade de inovação e espírito 
de mudança. A maturidade na GSTI só virá com a prática da inovação. 
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Preparar a empresa para a GSTI 
Preparar a TI para a GSTI 
Construir um CMDB 
Construir um Catálogo de Serviços 


Construir Acordos de Nível de Serviço 


Construir uma Base de Conhecimento 


Implantar processos operacionais 


SERÁ QUE ESTE REALMENTE É O LUGAR PARA SE COMEÇAR? 


Uma discussão que frequentemente ronda as rodas de conversa sobre 
GSTI e ITILº é: Por qual processo devemos começar se já temos um am- 
biente operando? Já comentamos a questão rapidamente nos capítulos an- 
teriores, mas aqui vamos nos aprofundar um pouco mais, sempre com a vi- 
são da inovação. Lembre-se: se você não “trocar de cadeira” para observar o 
mesmo elemento sobre outro ponto de vista, nunca vai descobrir coisas que 
sempre estiveram lá, mas que continuam desconhecidas. 

As estatísticas existentes no mercado apontam que o processo mais co- 
mumente implantado é a gestão de incidentes. Isso poderia levar muitos a 
engordar ainda mais esta estatística, também se iniciando por este processo. 
Porém, há de se refletir que não é porque todos fizeram de tal maneira até 
hoje que temos que continuar neste mesmo rumo. 

É claro que é muito mais fácil encontrar exemplos, modelos, experiências, 
cases, documentos e até gente falando de gestão de incidentes do que falando 
de gestão de configuração. Se mais gente faz gestão de incidentes, então mais 
gente também fará, isso faz parte da inércia que já comentamos. Mas aqui 
não estamos discutindo qual é o processo mais usado. Vamos discutir qual 
deveria ser o primeiro processo a ser inserido para nos assegurar melhores 
condições de sucesso na implantação e operação de um service desk, que é 
um dos principais objetivos de muitos dos projetos. 

É realmente muito difícil, e até perigoso, afirmar que existe um primeiro 
processo ou que se pode definir uma ordem para a implantação de processos. 
Porém, o ponto de vista que vamos apresentar é baseado naquilo “que ve- 
mos sentados na nossa cadeira” quando olhamos para este desafio: implantar 


uma pequena parte da GSTI criando e operando nosso service desk. Outras 
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pessoas “sentadas em outras cadeiras” poderão defender outros pontos de 
vista e mostrar outros aspectos importantes. Como já dissemos, não existirão 
verdades absolutas. Cada um, pelo seu ponto de vista, desde que observando 
sempre o mesmo modelo e sendo fiel ao que vê, poderá vislumbrar diferentes 


aspectos e produzir diferentes resultados. 


QUE EXEMPLO DEVEMOS SEGUIR? 


Muitas vezes, para inovar na nossa área de atuação, não precisamos criar 
algo realmente revolucionário. Pode parecer um contrassenso, mas, para 
inovar, frequentemente devemos copiar. Copiar algo que é feito em outro 
ambiente e que produz bons resultados lá, derivando regras e mimetizando 
comportamentos pode, sim, ser uma grande inovação. 

Se buscarmos exemplos de diversas invenções já criadas poderemos ver 
que insetos, animais, plantas e até comportamentos de eventos da natureza 
podem ter sido usados como ideias para geração de inovações. Recentemen- 
te, foi exibida na T'V uma reportagem mostrando a criação de um dispositivo 
que permitiria que paraplégicos pudessem andar. Este invento foi baseado 
no conceito dos exoesqueletos de insetos produzindo a capacidade de sus- 
tentação do peso do corpo de uma pessoa não mais através de seu endoes- 
queleto e de seus músculos, mas através de um dispositivo de sustentação e 
movimentação externo. Então, vamos seguir a analogia e procurar identificar 
onde as demais áreas de gestão buscam embasamento para a sustentação de 
suas atividades e para atingir seus objetivos. Se esta observação demonstrar 
algum elemento em comum, poderemos transportar o mesmo conceito para 
a GSTI e aplicá-lo de modo inovador. 

Vamos pegar duas áreas de gestão clássicas e que já passaram por di- 
versas oportunidades de validação de suas estratégias: a gestão de recursos 
humanos e a gestão contábil. Cada uma bastante distinta da outra quanto 
aos elementos que manipula: a gestão de RH tratando de recursos tangíveis 
e a gestão contábil, de recursos intangíveis. Uma com forte aspecto de rela- 


cionamento pessoal, outra com forte aspecto de relacionamento impessoal. 
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Vamos então à análise não das diferenças, mas de um ponto que elas têm 
em comum para o atingimento de seus objetivos: o controle detalhado dos 
itens que gerenciam! 

O que seria da gestão de RH cheia de processos, políticas, estratégias, 
técnicas e tecnologias se ela não tivesse um cadastro de pessoal rico em in- 
formações, atualizado, confiável e íntegro? E o que seria da gestão contábil, 
também com todos os seus processos, regras, normas, técnicas e tecnologias 
se ela não tivesse um cadastro de contas contábeis bem organizado, confiável 
etc.? É possível reconhecer nestes dois casos que a produção de resultados 
efetivos em todos os processos destes dois ambientes de gestão depende, 


essencialmente, de fontes de informação confiáveis. 
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Cadastros de base 


Não podemos imaginar uma área de gestão de recursos humanos sendo 
criada num instante inicial em uma organização sem que na primeira fase 
deste projeto sejam feitas a definição de um cadastro de informações, a coleta 
de informações sobre os funcionários, a alimentação desta base de dados e a 
preparação de procedimentos, políticas e estratégias para garantir que estes 
dados se mantenham sempre íntegros e disponíveis. 

Teria qualquer ambiente de gestão de recursos humanos em qualquer 
organização e em qualquer tempo se iniciado pelo processo de gestão de 
atendimento a solicitações recebidas pela área de RH? Mesmo antes de ter 
um cadastro de funcionários criados? É muito pouco provável. Todos os am- 
bientes de gestão priorizam o controle sobre seu “patrimônio”, ou seja, sobre 


os itens que gerenciarão, pois, se não tiverem estrito domínio sobre eles, a 
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efetiva validade da gestão atual pode ser questionada. E na TI, como este 


conceito tem sido aplicado? 


LIÇÕES APRENDIDAS: O melhor lugar para se começar é pelo começo. Podemos 
sempre aprender com as experiências de outros ambientes de gestão corporativa. 
Além de nos servir como referência, poderão servir também como analogia para 


repassar conceitos aos nossos clientes. 


A TITEM SEGUIDO ESTES EXEMPLOS? 


À experiência mostra que poucas empresas têm dado prioridade a um pro- 
cesso de gestão de configuração no início de seus projetos de GSTI. Quando 
muito, ao questionarmos sobre o controle existente, a resposta que obtemos 
é que existe um controle de inventário, porém também não muito preciso. 
Existem gerentes de TI dizendo: “Aqui não adianta a gente querer controlar, 
pois as coisas mudam tanto que já tentamos três ou quatro vezes fazer um 
inventário, e nem bem ele acabou e já estava desatualizado.” Alguém já ouviu 
algo parecido? Já pensou algo parecido? Talvez. Mas qual será o real motivo 
para não se ter um controle preciso? Será que falta conhecimento de como 
fazer? Será que falta tempo para fazer? Será que falta gente para fazer? Quem 
sabe todas estas coisas juntas? Quem sabe nenhuma delas? Pense. 

O primeiro ponto que é abordado quando muitos pensam em implantar 
a GSTI é começar pelo service desk. Para estas pessoas, a ITILO é sinônimo 
de service desk, e service desk é sinônimo de gestão de incidentes. Este é o 
time que continuará a operar um help desk, pensará como um help desk, agi- 
rá como um help desk, será visto como um help desk e pior: será reconhecido 
pela organização e pela alta direção como um help desk, apesar de se intitular 
um service desk. Resultado: não vai mesmo conseguir justificar que precisa 
de recursos adicionais para implantar um service desk. Isso nos leva àquele 
dito popular que diz mais ou menos assim: “Se tem pata de elefante, tromba 
de elefante, rabo de elefante, corpo de elefante, peso de elefante, cor de ele- 


fante, tamanho de elefante, faz barulho de elefante, então é elefante.” 
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Se você quer ser reconhecido como um service desk, você precisa agir 
como um service desk, ser estruturado como um service desk, ter atividades 
de service desk, ter recursos que um service desk tem, ter responsabilidades 


de um service desk e ter indicadores de service desk. 


um service desk 


É um service desk se... 


Não dá para dizer que você um dia será um service desk se não tem um 
CMDB, não tem processos de atualização do CMDB, não usa o CMDB 
durante os atendimentos, não mantém um CMDB. É como dizer que algo 
é um elefante, mas não tem tromba, nem peso, nem cor, nem tamanho, nem 
pata de elefante. Ninguém irá acreditar. Você pode até se enganar e dizer que 
tem um service desk na sua empresa, mas um dia nem você mais vai acreditar 
nisto. 

Se a organização em que você vai implantar a GSTI não tiverum CMDB, 
crie. Se já tiver e não tiver integridade, implemente processos que garantam 
a integridade. Se já teve um CMDB e desistiu de ter, mostre novamente o 
caminho para voltar a tê-lo. 

Comece inovando e fazendo aquilo que as demais áreas de gestão fazem: 
organize seu acervo. Assim, da próxima vez em que ligarem para registrar um 
incidente, seu técnico não vai precisar perguntar: “Que versão de Windows 
você tem aí na sua máquina?” Ele poderá dizer: “Qual é o problema que 
você tem com seu Windows Vista, instalado na semana passada?” Isso dá 
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credibilidade. Dá segurança para quem está sendo atendido, dá a visão de 
que a gerência de TI realmente gerencia o acervo pelo qual é responsável. 
Imagine você ligando para o RH para pedir uma informação e a pessoa 
que lhe atendeu lhe perguntando: “Você poderia me informar que dia foi 
contratado?” O que você pensaria de um departamento de RH que nem sabe 
o dia em que você começou a trabalhar na empresa? Você conseguiria acre- 


ditar que eles realmente fazem gestão de RH? 


LIÇÕES APRENDIDAS: O CMDB é a base de toda a GSTI. Se todas as demais 
áreas de gestão começam pela estruturação de uma base de dados sobre os itens 
básicos que irão manipular, então por que não fazer a mesma coisa na GSTI? 


AS PESSOAS ENTENDERAM O QUE DEVE SER FEITO? 


O exemplo que citamos anteriormente é só o começo de uma linha de 
raciocínio que gostaria que você acompanhasse. Se a gestão de RH, para ser 
vista como tal, deve gerenciar recursos humanos, então seria de se esperar 
que a TI, como provedora de serviços através de recursos de TI, também 
gerenciasse estes recursos. Esse deveria ser o objetivo principal da área, mas 
ele se perdeu “em algum instante da história”, assim como naqueles filmes 
de pessoas que voltam ao passado e, de repente, por algum fato inesperado, 
tomam um rumo diferente e toda a história de suas vidas lá no futuro pode 
se modificar irremediavelmente. 

Tudo indica que a gestão de TI tenha nascido para gerenciar recursos e 
serviços de TI, mas algum fato fez com que aqueles “nerds”, que no começo 
da história da TI eram vistos quase como “gênios que sabiam operar os com- 
putadores”, acabassem por ser reconhecidos como “o pessoal que resolve to- 
dos os problemas quando eles surgem”. Isso deve ter criado um estímulo para 
que as pessoas deixassem de gerenciar recursos e serviços de TI e passassem a 


se preocupar excessivamente com a manutenção daquilo que produziam. 
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O perfil de comportamento do ser humano também deve ter tido grande 
influência no rumo em que as coisas tomaram. Quem não gostaria de ser 
reconhecido como “quem resolve todos os problemas que surgem”? Seria 
melhor ficar “trancafiado na masmorra” fazendo gestão de recursos e ser- 
viços enquanto os demais, em constante contato com os usuários, recebiam 
“os louros” da resolução de dúvidas e problemas? Não. Alguns podem ter 
pensado: “Se eu quero ser visto e lembrado então estarei envolvido com ati- 
vidades de suporte e deixarei que alguém assuma as tarefas de retaguarda, tais 
como atualizar cadastros, fazer controles etc.” E “todos” deixaram isso para 
“alguém” fazer, e “alguém” deixou para “ninguém” fazer. Dá para imaginar 
aonde a situação pararia, não dá? O pior é que até hoje vemos pessoas com 
este pensamento. 

Outra questão que, provavelmente, também foi motivadora de uma dis- 
torção de objetivos e de foco da TI foi o fato de que, por não planejar e 
gerenciar corretamente os recursos existentes, criavam-se então, de forma 
desestruturada, novos “recursos” que em curto espaço de tempo passavam a 
apresentar necessidades de ajustes, de correção de problemas etc., acabando 
por gerar um círculo vicioso: “Não se faz gestão porque não se tem tempo e 
não se tem tempo porque não se faz gestão.” 

Deste ponto em diante, a visão de que o que devia ser feito era manter a 
todo custo os “artefatos” gerados passou a dominar a mente da maioria. Uma 
ideia, então, se estabeleceu: “Se eu não tenho tempo para fazer tudo o que 
tem que ser feito, então a gestão pode ter menor foco e o suporte é que me- 
rece destaque.” Ainda hoje vemos empresas trabalhando deste modo. É nelas 
que encontramos pessoas que dizem: “O que eu preciso mesmo é de um sis- 
tema bem simples no qual eu possa só registrar todos os pedidos e controlar 
as filas do que tem para ser feito.” É a indústria do atendimento de pedidos. 
Não interessa mais se eles são pertinentes ou não, se poderiam ser reduzidos 
ou não, se poderiam ser executados de um modo mais ágil ou não. O que 
interessa é cumprir prazos. Cada um cumpre sua cota diária e amanhã será 
um dia exatamente igual ao de hoje, ou pior. Acredite, isso ainda existe! É 
um dos desafios que teremos que enfrentar com todas as estratégias e lições 


aprendidas até aqui. 
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LIÇÕES APRENDIDAS: Independentemente dos motivos que tenham levado uma 
área de TI a deixar de executar algumas atividades essenciais, não podemos dei- 
xar de reconhecer que estas atividades são inerentes e obrigatórias ao ambiente. 
Elas devem ser reestabelecidas assim que possível, pois continuarão a ser sem- 
pre essenciais. 


TEMOS RECURSOS PARA EXECUTAR AS ATIVIDADES 
NECESSÁRIAS? 


Tarefas de retaguarda, tais como criar e manter um CMDB, quando co- 
locadas numa lista de atividades a serem executadas, são, via de regra, dei- 
xadas pelas pessoas para a lista das atividades opcionais. “Faremos quando 
der tempo”, dizem. Lamento informar: não vai dar tempo! Se esperarmos 
o tempo sobrar para então executar atividades que são essenciais para nossa 
gestão, então estaremos não com um, mas com dois problemas de gestão: 
nem a tarefa será feita nem a definição de prioridade da gestão está correta. 

Como já vimos, é muito provável que a maior parte das organizações hoje 
não tenha realmente todos os recursos necessários para atuar em todas as ati- 
vidades que deveria estar executando. Isto fica pior ainda se considerarmos 
que, como nunca nos dedicamos, por exemplo, a criar e manter um CMDB, 
teremos ainda mais tarefas represadas, o que pode significar um déficit cada 
dia maior. Isto, entretanto, não significa que as atividades não poderão ou não 
deverão ser feitas. Lembre-se: os resultados é que devem guiar os processos. 

Se um processo de gestão de configuração puder ser justificado através 
de resultados, então os recursos poderão ser também justificados e alocados. 
Precisamos demonstrar que mesmo que recursos adicionais sejam necessá- 
rios, eles não representarão custos, mas sim investimentos. Se uma pessoa 
adicional na equipe for necessária, talvez em dois ou três meses ela não seja 
mais necessária e talvez até permita que outra pessoa seja liberada, pois com 
a otimização de outros processos poderemos liberar recursos. Se mesmo as- 


sim isto não acontecer, talvez a alocação desta nova pessoa numa atividade 
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de retaguarda sirva para promover uma melhoria no atendimento e reduzir 
o tempo de reparo de um serviço que possa impactar a produção ou o fatu- 
ramento da empresa. Neste caso, a relação custo-benefício é que tem que 
ser avaliada com uma visão corporativa. E ela poderá ser positiva, apesar dos 


custos adicionais. 


Resultados 


è obtidos â 


Portanto, recursos nem sempre estão disponíveis, mas eles podem ser 


providos para um processo desde que os resultados justifiquem. Como você 
pensa que as empresas que hoje mantêm um processo de gestão de configu- 
ração conseguiram os recursos para estas atividades? Pode ter certeza de que, 
tanto no ambiente público como no ambiente privado, não há excesso de 
recursos. O que existem são políticas de aplicação e priorização. Se não ino- 
varmos, não buscarmos “sentar em outra cadeira” para ter um novo ponto de 
vista, continuaremos reféns de um circulo vicioso no qual as melhorias não 
serão feitas por falta de recursos e nunca teremos recursos liberados porque 


melhorias não foram feitas. 


LIÇÕES APRENDIDAS: Processos de melhoria e otimização nunca são executados 
com recursos ociosos ou excedentes. Eles sempre requerem investimentos, ou 
seja, alocação de recursos adicionais. Para se obter mais ou melhores resultados 


teremos que alocar mais ou melhores recursos. 
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COMO DEVERÍAMOS FAZER? 


Quando o assunto é conseguir fazer mais com menos, ou conseguir ab- 
sorver mais atividades quando já estamos saturados, há sempre a ideia de que 
chegamos a um impasse, ou de que não há como superar a barreira da falta 
de recursos. 

Fazendo outra analogia, vou tentar apresentar um plano para atacar este 
problema. Imagine que certo soldado romano recebeu a atribuição de entre- 
gar uma correspondência endereçada a um general numa província muito 
distante. Ele, como bom romano que é, obstinado a cumprir seu objetivo, 
inicia sua caminhada pela estrada que o levará à província. Chegando a certo 
ponto da estrada percebe que seu objetivo poderá ser frustrado, pois uma 
ponte que cruzava um penhasco havia caído. Sem pestanejar ele retorna cin- 
co quilômetros pela estrada por onde vira, pega outro caminho e chega ao seu 
destino, atrasado, porém sem desistir de sua missão. O que esta história nos 
ensina? Que mesmo que nosso objetivo seja caminhar para a frente, às vezes 
temos que voltar, retroagir, para seguir. 


obstáculo 


Vamos então aplicar esta regra à gestão de configuração e à construção de 
um CMDB em um ambiente que esteja buscando implantar a GSTI. Nosso 
objetivo neste projeto é seguir em frente e implantar a GSTI com sucesso. 
Nossa empresa está hoje num estágio no qual não se aplicam as melhores 
práticas da TTILº na área de atendimento. Ela tem somente um help desk 


reativo e gostaria de ter um service desk proativo, efetivo e produzindo mais 
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com menos. Um cenário muito comum em vários projetos, com certeza. O 
que poderíamos, então, fazer? Andar para trás para depois poder ir para a 
frente! O que isso significa? Significa que se hoje a área de atendimento já é 
um help desk sem melhores práticas, nós talvez tenhamos que permanecer 
assim por mais dois ou três meses e ainda solicitar que atividades extras sejam 
absorvidas pela equipe de help desk. Lembre-se: vai parecer um contrassenso 
deixar as coisas como estão (sem melhores práticas) e ainda piorar o cenário 
colocando ainda mais atividades a serem feitas. Vai ser difícil conter as ex- 
pectativas de ver uma gestão de incidentes se iniciando logo. 

Mas de que adiantaria iniciarmos um processo de gestão de incidentes 
se não temos a base de dados mais importante deste processo? Muitos 
acham que a base mais importante é a de registro de incidentes, a de erros 
conhecidos, ou a de conhecimento. Ok, todas são importantes, mas a mais 
importante é o CMDB. Ele é o mapa do terreno aonde iremos “travar a 
batalha”, e olha que até os piratas, que eram “destemidos”, já aceitavam o 
fato de que “sem um bom mapa não é possível achar o tesouro”. Será que 
você é mais corajoso que eles? Ou talvez corajoso não seja bem a palavra? 

A ideia então é esta: prepare os elementos essenciais que você precisa 
antes de se lançar numa nova empreitada, mesmo que sua empresa tenha 
a demanda, mesmo que julgue que os pré-requisitos podem ser deixados 
para mais tarde (seriam então pós-requisitos?). Adie qualquer iniciativa 
de colocar em operação novos processos e dedique-se à criação de um 
CMDB, mesmo que básico. Ele não precisa ser completo, só precisa ser 


correto. 


LIÇÕES APRENDIDAS: Investir tempo para prover recursos que sejam pré-requi- 
sitos para outras atividades pode ser visto como um retrocesso, mas, se este 
investimento não for feito na hora certa, ele precisará ser feito mais tarde com 
custos ainda maiores. Se não houver investimento no início, não haverá lucros 
no futuro. 
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QUAL A IMPORTÂNCIA DE SE FAZER? 


Ter um CMDB ou não poderá significar a diferença entre um processo de 
gestão de incidentes melhor ou pior. Poderá também fazer a diferença entre 
um processo de gestão de mudanças mais ou menos ágil. Em resumo: ter um 
CMDB poderá significar ter ou não melhores processos. 

Melhores processos não existirão somente porque foram concebidos e 
desenhados de um modo diferente. Existe uma expectativa muito grande 
colocada em processos novos. Às vezes, as pessoas esperam que nós, como 
consultores, tenhamos uma “carta na manga” que possa fazer com que um 
processo inovador seja criado e resolva todos os seus problemas. Outros 
vão até a documentação oficial da ITILº ou diversos sites espalhados pela 
web que publicam modelos de processos e pensam ter encontrado a solu- 
ção que buscavam. Muitos até implementam esses processos e depois de 
algum tempo não conseguem ver efetivamente as melhorias surgirem. Nem 
poderiam. 

Se nos lembrarmos do conceito básico de processos visto nos cursos de 
ITIL Foundationsº, veremos que ele envolve algo muito clássico: entradas, 
atividades, saídas. Pois bem, aquelas pessoas que só se concentram sobre as 
atividades de um processo estão esquecendo-se das entradas! Principalmente 
de entradas tais como o CMDB, o Catálogo de Serviços, os Acordos de 
Nível de Serviço etc. 

Algumas pessoas, ao analisarem o processo de gestão de incidentes, di- 
zem: “Eu pensei que as entradas eram os chamados que eram abertos e que 
as saídas eram as soluções produzidas.” Não estão errados, porém existem 
outras entradas que foram esquecidas. Sem bases de dados de RH, os pro- 
cessos de gestão de RH não sobreviveriam, como você deve estar lembrado. 
A afirmativa também vale para os processos de gestão de serviços de TI. E 
não é só isso. O CMDB, além de ser uma entrada importante, é também 
uma saída importante! 

Não podemos nos esquecer de que um simples chamado de solicitação de 
transferência de um microcomputador de uma sala para outra, após executa- 


do pelo service desk, deve produzir algum tipo de atividade que garanta que 
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a atualização do CMDB espelhe a transferência executada, ou teremos em 
pouco tempo outro significado para CMDB: “O Cadastro Mais Desatuali- 


zado do Brasil”, concordam? 


LIÇÕES APRENDIDAS: A ITIL® é baseada em processos. Processos são baseados 
em entradas para produzirem saídas. Muitas pessoas querem produzir melhores 
saídas, mas não estão dispostas a fornecer melhores entradas. Isso pode produzir 
um impasse ou até tornar inviável a produção das saídas desejadas. 


QUAL O RISCO DE NÃO FAZER? 


Muitas empresas justificam que não possuem um CMDB estruturado e 
bem alimentado porque não têm recursos para alocar para estas atividades. 
Já dissemos que isso ocorre porque se cria um círculo vicioso no qual “não se 
faz porque não há tempo e não há tempo porque não se faz”. Como já vimos, 
a existência de um CMDB pode ser um elemento que irá agregar facilidades 
na execução de diversos outros processos, tornando-os mais ágeis e rápidos, 
liberando, portanto, recursos. 

O fato de não termos um CMDB e também processos que o mantenham 
atualizado e confiável pode produzir outro efeito de círculo vicioso: “Não 
fazemos gestão porque não temos recursos e não temos recursos porque não 
fazemos gestão.” Num cenário como este, como o diretor de uma empresa 
pensaria em liberar mais recursos financeiros, por exemplo, para contratar 
mais pessoas para a área de TI, se nem a informação precisa sobre o total de 
equipamentos existentes na rede o gerente de TI é capaz de apresentar quan- 
do inquirido numa reunião? Que créditos têm uma gerência de TI que de- 
sistiu de controlar seu inventário? Coloque-se no lugar do diretor financeiro: 
você aportaria mais recursos para uma área que já decretou incapacidade de 


executar suas atividades de gestão? 


113 


ITIL - GUIA DE IMPLANTAÇÃO 


Sorria, você está sendo filmado! 


Isso significa que a ausência de um CMDB pode ter impactos diretos e 
indiretos nos demais processos ITILº e até no próprio processo de gestão 
de serviços de TI. Pode fazer com que a credibilidade da gestão executada 
seja colocada em xeque. Pode fazer com que a confiança dos clientes da TI 
se reduza, pois a ideia de que a TI está operando sem conhecer seu próprio 
acervo pode levá-los a duvidar da efetividade de sua atuação. E pior que tudo 
isso: pode gerar ainda mais sentimento de liberdade e impunidade para os 
clientes da TI quando eles alterarem sem permissão configurações de equi- 
pamentos, equipamentos de sala etc. O pensamento que pode se estabelecer 
é: “Se a TI não tem controle efetivo sobre estes itens, então por que eu não 
mexeria neles? Se eu mexer nunca serei detectado...” Teremos então mais um 
círculo vicioso: “A TI não controla porque as coisas mudam sem permissão, 
e as coisas mudam sem permissão porque a TI não controla.” Estará, então, 


estabelecido o caos. 


LIÇÕES APRENDIDAS: A GSTI só poderá realmente ser praticada se tivermos con- 
trole sobre o ambiente. Quem não registra não mede. Quem não mede não con- 
trola. Quem não controla não faz gestão. Não é possível dizer que se faz GSTI se 
não há controle sobre os itens essenciais que ela manipula. 


POR ONDE COMEÇAR? 


A grande parte das pessoas quando fala em aplicar as melhores práticas 
da ITILº à GSTI imagina que isto significa se dedicar a novos processos 
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ligados diretamente à operação do service desk: incidentes, mudanças, re- 
quisições, eventos, problemas etc. Talvez porque exista uma visão de que 
os processos atuais que executam em seus ambientes de atendimento não 
sejam bons, logo deveriam ter novos processos. Será que estas pessoas já 
pararam para avaliar por que suas operações não são tão boas quanto elas 
desejariam? 

Já vimos no Capítulo 2 que a TI precisa mudar seu ponto de vista. 
O que pode estar faltando não são somente processos adequados, mas a 
adoção de premissas, a criação de artefatos de apoio, o estabelecimento de 
políticas e regras, a adoção de comportamentos diferenciados. Entre os ar- 
tefatos de apoio que consideramos essenciais está, sem dúvida, o CMDB. 
Para sua criação e manutenção algumas iniciativas devem ser adotadas, 


entre elas: 


Aplicar o 
conceito de 
melhoria 
contínua 


Definir um 
escopo 
exequível 


Focar nos 


Criar valor 
resultados 


Criar valor 


À primeira iniciativa que se deveria buscar seria demonstrar a todos os en- 
volvidos nos processos de gestão de serviços de TI a importância do CMDB. 
Não conseguiremos criar e manter um CMDB sem que seja estabelecido 
o real grau de importância dele, dentro e fora da TI. Dentro da TI, para 
que as pessoas possam se engajar nas atividades de criação e manutenção do 
CMDB, compreendendo, cada um, o seu real papel. Fora da TI, para que as 
pessoas possam entender a necessidade da existência de processo de gestão 
de configuração, de políticas de gestão de itens de configuração, de regras e 
exigências de restrição a mudanças não autorizadas etc. 

À organização precisa reconhecer o papel do CMDB como um elemento 
de garantia de continuidade de suas atividades de negócio. Se uma visão 
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corporativa for estabelecida poderemos ter o apoio de áreas estratégicas para 
nossas iniciativas. Este apoio pode e deve (segundo a ITIL®) ser traduzido 
em políticas organizacionais, não somente em decisões pessoais ou departa- 
mentais. Políticas são documentos que se integram não só aos processos de 
negócio, mas à visão e à missão da organização. Quando políticas organiza- 
cionais passarem a ser criadas referenciando a GSTI, ou até mesmo espe- 
cificamente o CMDB, teremos, então, atingido o nível de reconhecimento 


necessário ao tema. 


LIÇÕES APRENDIDAS: Não são as pessoas que devem ser convencidas da im- 
portância do CMDB, mas a organização como um todo. O reconhecimento cor- 
porativo desta importância irá criar um valor de longo prazo. O reconhecimento 
das pessoas pode ser passageiro. Invista em ações que deem resultado de longo 
prazo. 


Definir um escopo exequível 


Os conceitos de gestão de configuração que são repassados nos treina- 
mentos de ITIL Foundationsº já destacam, para aqueles que irão implantar 
este processo, o fato de que uma das primeiras atividades deve ser a definição 
do escopo do processo. Não vamos nos ater aqui aos conceitos, mas à aplica- 
ção deles, pois este é nosso objetivo em todo o livro. Todos sabem que definir 
um escopo é essencial e que ele não deve ser nem muito abrangente nem 
muito restrito. É isso o que nos diz a teoria. Mas como definir em que escala 
intermediária ficaremos entre o abrangente e o restrito? Existem empresas 
que não sabem precisamente nem quantos micros possuem no seu parque de 
equipamentos e querem já na primeira fase de implantação do processo de 
gestão de configuração ter um nível tão detalhado de inventário de equipa- 
mentos que chegam ao ponto de desejar manter no CMDB até o fabricante 


de cada pente de memória instalado nos equipamentos. 
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O que isso nos ensina? Que devemos analisar o GAP que precisamos 
preencher. Não podemos, como implantadores de um processo de gestão de 
configuração, estabelecer um escopo padronizado para todas as empresas. 
Tudo vai depender de onde estão agora e dos recursos que possuem para dar 
o próximo passo. Precisamos respeitar o nível de maturidade atual e a capa- 


cidade de desenvolvimento para então definir aonde chegaremos. 


PARA 


ONDE ESTAMOS? ONDE ESTAMOS? 


AONDE QUEREMOS CHEGAR? COMO PODEREMOS IR? 


DE 


DEDUZINDO SE, ENTÃO: COMO DEDUZINDO SE, ENTÃO: AONDE 


CHEGAREMOS? PODEREMOS CHEGAR? 


Talvez esta abordagem contrarie, de certo modo, o modelo de “onde es- 
tamos — aonde queremos chegar — como chegaremos”. No modelo clássico, 
primeiro reconhecemos onde estamos, depois aonde queremos chegar, para, 
então, criarmos um caminho que nos leve até lá. Na abordagem alternati- 
va que estamos propondo aqui definiremos primeiro onde estamos, depois 
como podemos caminhar, e, em seguida, descobrimos até onde poderemos 
ir. Definiremos um objetivo baseado nos recursos de que dispomos. À restri- 
ção são os recursos, então talvez possamos nos adequar a ela. 

Criando uma analogia com esses dois modelos, poderíamos afirmar que, 
no modelo clássico, nós identificamos que estamos em Curitiba, queremos 
chegar até Recife no mesmo dia, então definimos que iremos de avião. Já 
no modelo proposto, nós sabemos que estamos em Curitiba, identificamos 
que só poderemos ir de ônibus, pois não temos dinheiro para o avião, logo 
descobrimos que chegaremos a Recife somente depois de uma semana. 


Este é um modelo baseado em restrições. Se já conhecemos as restrições 
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e temos que nos adequar a elas, então o que nos resta é saber até onde 
conseguiremos ir nesta primeira etapa de nossa iniciativa, respeitando as 


restrições. 


LIÇÕES APRENDIDAS: Existem dois tipos de limitação com as quais devemos lidar: 
aquelas que são transponíveis e aquelas que são instransponíveis. Procure supe- 
rar as primeiras e se adaptar às segundas. As limitações intransponíveis poderão 
se transformar em transponíveis ao longo do tempo, portanto não deixe de focar 
nelas continuamente. 


Aplicar o conceito de melhoria contínua 


A abordagem anteriormente apresentada de um modelo de execução ba- 
seado em restrições é totalmente aderente ao conceito de melhoria contínua 
proposto pela ITILº. Esta visão é um dos fatores essenciais para o sucesso 
da implantação não só do processo de gestão de configuração, mas de todos 
os demais processos da ITILº. 

Muitas pessoas, e até empresas, procuram definir ou redefinir seus proces- 
sos operacionais agregando as melhores práticas sugeridas pela ITILº sem 
respeitar o modelo de restrições. Esquecem-se de fazer as considerações so- 
bre o cenário de uma determinada empresa e, aplicando simplesmente uma 
abordagem “by-the-book”, geram uma situação de incompatibilidade entre 
o desejado e o alcançado. É o que chamamos de falta de “ajuste do tamanho 
do passo”. 

A ITIL® nos mostra os passos a serem dados, mas não o tamanho do 
passo que devemos dar de cada vez. Indiretamente, até nos diz que devemos 
dar vários passos e não um único, pois sugere no processo de melhoria con- 
tínua que devemos fazer sucessivas melhorias gradativamente. Isso é uma 
demonstração de que a ideia por trás da ITIL® é: “Faça pouco a pouco, mas 
faça sempre.” 
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Grandes projetos de implantação de gestão de serviço de TI aplicando 
ITILº que se alongam por intermináveis anos parecem ser um contrassenso. 
Parece que as pessoas querem, em um único passo, atingir um modelo de 
perfeição, então, as melhorias contínuas serão somente uma exceção a ser 
tratada quando uma irregularidade for encontrada e corrigida. A melhoria 
contínua é, na verdade, uma proposta de evolução de maturidade. Vamos 
começar a gestão de configuração com maturidade nível 1, para depois então 
buscar a maturidade nível 2 e assim por diante. Vencidas as restrições de um 
nível de maturidade, estaremos habilitados a seguir para o próximo nível. 

Este é mais um ponto que a V3 talvez ainda precise aprimorar, seguindo 
um modelo parecido com o que o Cobit® já propõe. Estabelecer níveis de 
maturidade possíveis para cada processo da ITIL® de acordo com as compe- 
tências desenvolvidas, com as melhores práticas já adotadas e com as carac- 
terísticas criadas nas organizações. 

O nível de maturidade por processo poderia permitir que as empresas se 
focassem em buscar pequenas conquistas a cada ciclo de melhoria conforme 
suas restrições. Aqueles que pudessem sair do nível O para o nível 3 direta- 
mente poderiam fazê-lo, já aqueles que do nível O pudessem só chegar até o 
nível 1 também já teriam desenvolvido uma nova maturidade. Hoje, muitas 
pessoas acreditam que ao saírem do curso da ITIL Foundationsº poderão 
chegar em suas empresas e começar um plano de implantação da GSTI que 
os leve do nível O para o nível 5 “num piscar de olhos”. Lamento dizer: estão 
enganados. 
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LIÇÕES APRENDIDAS: Não estabeleça metas muito arrojadas. “Pequenas vitórias” 
(quick wins) são melhores do que “grandes e intermináveis batalhas”. Se você 
quer conquistar “todo um território”, procure “vencer uma batalha de cada vez”. 
Respeite suas limitações na hora de definir o “tamanho do passo que irá dar”. 


Focar nos resultados 


Este parece um ponto repetitivo. E realmente é. Toda a ITILº sugere 
foco em resultados. Cada processo visa essencialmente resultados. Existem 
casos nos quais muitas pessoas acabaram se concentrando tanto em “como 
fazer” a gestão de configuração e a criação do seu CMDB, que se esquece- 
ram de “por que” estavam fazendo aquilo ou “para quem” estavam fazendo. 
Esse é um risco que qualquer abordagem metodológica, framework, mode- 
lo ou padronização traz: as pessoas podem virar escravas do “como chegar 
lá” e acabar esquecendo-se de definir realmente caminhos que “os façam 


29 


chegar lá”. 


Já vimos que realmente o formalismo, a padronização, o uso de regras, o 
estabelecimento de senso comum sobre alguns pontos etc., são itens impor- 
tantes para que um ambiente obtenha o correto uso dos recursos, a execução 
de atividade de modo mais produtivo, para que haja o correto estabeleci- 
mento de prioridades etc. Porém, a medida na qual estes elementos precisam 


ser agregados a um ambiente vai depender “do tamanho do passo que você 
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possa dar”. Aqui também vale um ditado popular: “Quem quer o ótimo, o 
bom nunca tem.” 

Pequenas conquistas que agregassem efetivamente resultados de melhoria 
na entrega de serviços deveriam ser nosso objetivo diário e contínuo. Tal- 
vez, inclusive, deste modo pudéssemos romper as barreiras da resistência às 
mudanças de modo mais fácil, sem radicalismos, sem conflitos, sem falta de 


recursos. 


LIÇÕES APRENDIDAS: Sempre estabeleça e destaque o resultado que será obtido 
com um plano de ação. Apresente sempre primeiro aquilo que será obtido, e só 
depois, como consequência, enumere o que deverá ser feito. Se as pessoas se 
concentrarem naquilo que querem obter poderão se convencer mais facilmente 


do esforço que deverão dispender. 


COMO EXECUTAR AS ATIVIDADES NECESSÁRIAS? 


À primeira pergunta que nos vem à mente quando falamos em construir 
um CMDB é: como devemos executar as atividades da gestão de configura- 
ção? À resposta é simples: uma de cada vez! Pode parecer trivial, mas essa é 
uma regra que nem sempre é seguida. As atividades do processo de gestão de 
configuração segundo a ITILº (planejamento, identificação, controle, regis- 
tro de status, verificação e auditoria) já nos mostram um simples, mas eficaz, 
roteiro. 

Não vamos nos deter em roteiros aqui, pois como já dissemos no prefácio, 
roteiros infalíveis não existem. O que iremos discutir são abordagens para 
cada uma destas atividades pressupondo que sejam realmente as melhores 
práticas. Se você analisar mais detalhadamente verá que também nesta abor- 
dagem proposta pela ITIL® mais uma vez a clássica abordagem do PDCA 
(plan-do-check-act) está presente. Logo, não há como negar que esta abor- 


dagem pode funcionar bem. 
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Planejamento 


As recomendações de abordagem para esta atividade já foram apresenta- 
das no item “Por onde começar?”. São pontos que podem lhe orientar para 
planejar a implantação do processo de gestão de configuração. O detalha- 
mento de subatividades desta e das demais não serão abordados, pois fazem 
parte da conceituação teórica sobre ITILº. Sugiro uma releitura do tema. 


Identificação 


Esta atividade, que parece ser uma das mais simples, talvez seja aquela que 
demandará mais cuidado ao ser executada. Muitas pessoas acreditam que o 
principal foco da identificação seja a descoberta dos itens de configuração 
(discovery) na rede. Esta ideia acaba sendo reforçada pela oferta no mercado 
de ferramentas de discovery, ou softwares de inventário automático, que se 
por um lado oferecem a grande facilidade de coletar informações, por outro 
lado induzem muitos ao mero controle quantitativo. 

Diferenciar a gestão de inventário da gestão de configuração deve ser nosso 
primeiro objetivo quando falamos em GSTI. Muitas pessoas envolvidas com 


os processos de TI, por já terem no passado se envolvido com processos de 
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gestão de inventário, acreditam que a gestão de configuração é só uma nova 
denominação para aquilo que já conheciam. Não falo somente daqueles que 
compõem a equipe da TI, mas também dos clientes da TI. Se, por um lado, a 
equipe da TI pode ter a falsa impressão de que fazendo um inventário de seu 
parque de equipamentos terá cumprido com a fase de identificação, por outro 
os clientes podem não entender por que a TI está investindo tanto tempo e 
recursos numa atividade que “um software pode realizar automaticamente”. 
Não podemos dizer que não exista algo de comum entre a gestão de inven- 
tário e a gestão de configuração: a gestão, isso é, quando ela realmente é feita. 
Por outro lado, existem também muitas diferenças entre elas. A primeira dife- 
rença é que o levantamento automático feito na gestão de inventário é muito 
mais quantitativo do que qualitativo. Ele também se baseia exclusivamente em 
itens de configuração acessíveis pela rede, ou seja, naqueles que estejam ativos e 
acessíveis na rede e para os quais consigamos algum tipo de interação via algum 
protocolo de comunicação (SNMP, WMI, IP etc). Todos sabemos que este 
pode ser um bom começo para a gestão de configuração, mas com certeza está 
muito aquém de nosso objetivo principal que é mapear muitos outros itens de 
configuração que ficariam fora deste simples levantamento. Logo, não importa 
se seu levantamento é automático, manual ou uma combinação dos dois. Há 
de se estabelecer um plano e métodos para atingir uma riqueza maior de ele- 
mentos e, principalmente, para inter-relacioná-los, o que, por sinal, é também 


a grande diferença da gestão de configuração. 


Q0 de Configura, : 
+) 


Gestão de 
Inventário 
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Como nos demais processos que já comentamos, será importante apre- 
sentar os benefícios que esta atividade irá gerar para o cliente e não para a 
TI. Não estaremos investindo tempo e recursos numa atividade porque nós 
temos interesse no resultado dela, mas porque o resultado é importante para 
o cliente. Precisamos acreditar nisso para poder transmitir a ideia. Este é 
um ponto importante: muitas pessoas têm um discurso pronto a apresentar 
quando se trata de justificar a execução de atividades de acordo com a ITIL® 
porque estão “do lado da mesa” da TI. Porém, basta que você coloque estas 
pessoas como clientes da TI, “do outro lado da mesa”, e elas não estarão mais 
dispostas a colaborar na mesma proporção. Como já dissemos, a questão não 
é “como fazer”, mas “por que fazer”. Seja o primeiro a comprar esta ideia e 


será muito mais fácil vendê-la. 


LIÇÕES APRENDIDAS: Não transfira a responsabilidade do controle e da gestão 
do CMDB para uma ferramenta qualquer. Como o próprio nome já diz, a ferra- 
menta é só um meio para você realizar uma atividade. Ela é muito importante, 
mas quem deve estar no comando é você. A ideia de que uma ferramenta pode 
automatizar um processo não é válida. Ela pode automatizar atividades, mas não 
todo o processo. 


Controle 


Boa parte da resistência existente nos ambientes de TI para aplicar tempo 
e recursos ao processo de gestão de configuração se deve a fracassos anterio- 
res na tentativa de controlar informações sobre o parque de equipamentos 
existentes. 

Existem empresas que após três ou quatro tentativas de manter seus da- 
dos atualizados, literalmente desistem de tentar controlá-los. Estas empresas 
relatam que não foi o levantamento das informações que gerou problemas, 


mas sim a falta de fidelidade entre as informações coletadas e as informações 
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reais existentes na rede depois de três ou quatro meses. Os dados coletados 
não traduziam mais a realidade da rede. Normalmente a justificativa para 
que isto ocorra é que “as coisas mudam e a TI não fica sabendo” ou que “as 
pessoas alteram coisas sem permissão”. 

Não foi por acaso que, entre as propostas de atividades que a ITIL® apre- 
sentou como melhores práticas, aparece uma atividade de controle que procura 
criar mecanismos para evitar estas alterações não autorizadas. Realmente não 
conseguiremos manter um CMDB sincronizado com a realidade se não nos 
dedicarmos em todos os demais processos (incidentes, mudanças, liberação, 
problema etc.) a criar atividades que assegurem esta integridade. Não se trata 
de proibir que as mudanças ocorram na rede, mas em controlar para que elas 
ocorram e sejam “reproduzidas” no CMDB fielmente. Por certo, poderá haver 
situações de anormalidade nas quais o sincronismo tenda a ser perdido, mas 
mesmo nestas situações deveremos estar preparados para restabelecê-lo. 

O que isso significa? Que deveremos ter processos não só para o levan- 
tamento, mas também para o reconhecimento da perda de sincronismo e 
para a eventual sincronização. Significa também que precisamos identificar 
as causas da perda do sincronismo para atuar sobre elas. Aquelas mesmas 
empresas que dizem já ter feito vários levantamentos, mas que nunca con- 
seguem manter o sincronismo, continuarão a não ter sincronismo enquanto 
não atuarem nas causas deste problema. 

São as técnicas da gestão de problemas aplicadas ao aperfeiçoamento de 
processos e não só de serviços. Se há perda de sincronismo devemos buscar a 
causa deste problema. A causa, normalmente, está associada ao fato de que o 
usuário altera configurações e não comunica, portanto, inibir o usuário de fa- 
zer estas modificações pode ser atuar sobre o fato gerador das divergências. 

Talvez a causa real do problema não seja o usuário deixar de comunicar 
quando altera, mas, sim, o fato de ele estar alterando sem ter permissão, 
portanto, inibir as alterações será uma ação efetiva. Se ele insistir em alterar, 
crie mecanismos que detectem esta alteração e comuniquem imediatamente 
o responsável pelo CMDB. Muitas vezes o que deveremos fazer não será 
alterar o CMDB para refletir a mudança não autorizada, mas, sim, desfazer 


a alteração na rede, mantendo o CMDB sem alteração. 
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LIÇÕES APRENDIDAS: Sem controle, todo o processo de identificação e coleta de 
informações estará comprometido. Controles exigirão regras, políticas e normas. 
Controles poderão gerar cobranças e conflitos. Você irá descobrir falhas e não 
conformidades. Não procure culpados. Procure melhorias nos processos. 


Registro do status 


Considere que as mudanças não autorizadas tenham sido inibidas até o 
nível em que deixem de afetar significativamente a integridade do CMDB. 
Restarão ainda as mudanças autorizadas que terão que ser refletidas no 
CMDB durante todo o ciclo de vida dos itens de configuração. Este cuidado 
deve ser tomado quando se definirem os processos de mudança, liberação, 
validação, entre outros. 

Aqui cabe um destaque a um ponto que muitas vezes parece pouco com- 
preendido, principalmente por aqueles que têm somente a formação de ITIL 
Foundationsº: a integração entre processos. Muitas pessoas visualizam os 
processos como se fossem monolíticos, ou seja, a gestão de configuração tem 
um começo, meio e fim, somente tratando de itens de configuração. 

Isso ocorre porque na abordagem teórica dos fundamentos acaba-se por 
se dar pouco destaque à grande interação que quase todos os processos têm 
com os demais. Lembre-se, porém, que algumas interações foram sim abor- 
dadas, entre elas a da gestão de incidentes com a gestão de problemas e tam- 
bém a interação entre as gestões de configuração, mudança e liberação. Estas 
interações, e outras que você poderá descobrir se aprofundando no tema, 
poderão assegurar uma correta atualização de status dos IC durante todo o 
seu ciclo de vida. 


LIÇÕES APRENDIDAS: Muito mais difícil do que criar um CMDB é mantê-lo atualiza- 
do. Antes de definir como irá coletar, pergunte-se como é que você manterá atualiza- 
do aquilo que coletou. Se não houver como, talvez nem valha a pena coletar. 
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Verificação e auditoria 


Se considerarmos que estabelecemos processos de captura, registro, sin- 
cronização e atualização do nosso CMDB baseados nas melhores práticas 
da ITILS, por que então deveríamos pensar em atividades de verificação 
e auditoria? Não seria de se esperar que a integridade do CMDB estivesse 
garantida? Qual seria então a finalidade desta atividade? Provar que as coisas 
estão certas ou provar que as coisas estão erradas? 

As atividades ligadas à auditoria sempre correm o risco de serem vistas 
como um meio para detectar falhas, para apontar deficiências. Já vimos que a 
ITILº se baseia num ciclo de melhoria contínua, e melhorias podem ser pro- 
duzidas pela correção de deficiências ou pelo aperfeiçoamento daquilo que já 
está bom. Logo, uma ideia que deve ser repassada a todos os envolvidos com 
o processo de gestão de configuração é a de que manteremos uma atividade 
contínua de verificação e auditoria não só para encontrar falhas, mas também 
para provar que já conseguimos atingir completamente o nível de maturi- 
dade que desejávamos atingir e que, portanto, estamos prontos para “subir 
mais um degrau”. À verificação e auditoria pode, portanto, ser um processo 
de reconhecimento de que tudo foi feito tão bem que nada mais resta a fazer 
neste nível de maturidade. Pode ser o elemento que permitirá reconhecer o 
sucesso, e não o fracasso. 

A ideia de que será necessário constantemente fazer auditorias e verifica- 
ções no CMDB pode deixar a impressão de que por algum motivo os pro- 
cessos de gestão de configuração feitos pela TI não são suficientemente bons 
para garantir os resultados necessários. Porém, analisando outras áreas de 
gestão, podemos verificar que verificações e auditorias são bastante comuns 
como estratégia de validação. 


FECHADO PARA BALANÇO 
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Um exemplo muito comum é o do processo de recontagem de estoque 
feito anualmente em várias empresas. Observe uma grande loja de departa- 
mentos em um shopping center. Normalmente estas lojas têm um processo 
de controle de entrada e saída de mercadorias muito aperfeiçoado. Nenhum 
produto é colocado nas prateleiras sem que esta informação seja inserida no 
sistema. Da mesma maneira, nenhum produto é vendido sem que a quanti- 
dade seja atualizada no sistema. Assegura-se também que nenhum produto 
saia da loja sem ser através do processo de venda, utilizando-se mecanismos 
que impedem o roubo de mercadorias. Por que então estas lojas anualmente 
têm necessidade de recontagem de seus estoques? Será que os processos que 
eles executam não são suficientemente bons para evitar falhas no controle de 
seus estoques, ou será que com a recontagem eles desejam justamente provar 
que seus processos são tão bons que nada está diferente do que os sistemas 
indicam? 

Este exemplo não significa que nosso processo de verificação e auditoria 
deva obrigatoriamente ser um processo anual. Acredito, inclusive, que po- 
demos criar atividades de verificação e auditoria que estejam inseridas em 
atividades operacionais diárias, semanais e até eventuais. Deixar as verifica- 
ções para serem realizadas em períodos muito distantes pode inclusive ser 
prejudicial. 

Existem empresas, por exemplo, que definem como estratégia para veri- 
ficação e auditoria que um técnico, ao se deslocar para uma visita presencial 
para um atendimento de instalação de uma impressora, deva também verificar 
algumas características básicas do microcomputador ao qual esta impressora 
seria associada. Além de instalar a impressora ele, utilizará a visita para uma 
coleta presencial de algumas informações que futuramente serão confronta- 
das com os dados existentes no CMDB. Se alguma divergência for então en- 
contrada, os ajustes serão feitos e a busca da causa raiz para esta divergência 
será estudada e equacionada. Assim, o tratamento de uma simples solicitação 
de instalação de um item poderá produzir a identificação de divergências ou 
a verificação de exatidão de dados em outro item de configuração. 
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Pequenas verificações com maior frequência podem ser mais produtivas 
do que extensas verificações feitas em períodos muito longos. Muito prova- 
velmente você não terá recursos disponíveis para alocar num longo processo 
de verificação. Já se inserir uma ou duas atividades adicionais a serem exe- 
cutadas não em todas, mas em algumas atividades operacionais (no exemplo 
dado, poderíamos imaginar que, para cada cinco instalações, uma deveria ter 
dados verificados), talvez a sobrecarga não seja percebida e possa ser absor- 
vida. 

Também o fato de executarmos algumas verificações associadas a ativida- 
des operacionais pode fazer com que elas não se destaquem demasiadamen- 
te, reduzindo assim a resistência que as pessoas terão a sua execução. Se você 
anunciar que no próximo mês fará uma verificação em todos os equipamen- 
tos da rede para verificar divergências, poderá ter uma grande resistência por 
parte dos clientes da TI. Já se algumas verificações forem feitas isoladamente 
durante outras atividades operacionais, um menor impacto poderá ser gerado 
entre os clientes da TI. 


LIÇÕES APRENDIDAS: Estabeleça o conceito de que a auditoria e a verificação 
são atividades que buscam demonstrar o nível de conformidade e não que procu- 
ram encontrar falhas. Estabeleça um nível de conformidade aceitável (90%, 95% 
etc.) e, quando atingido, parabenize as pessoas pela obtenção dos resultados, 
porém não deixe de mostrar que, segundo a melhoria contínua, este nível precisa 
sempre ser melhorado. Quando atingir 100% de conformidade, continue a cobrar 
melhorias, agora focado na otimização dos processos. 


COMO MANTER AS COISAS FUNCIONANDO? 


Como já vimos, criar um CMDB não é nosso maior desafio. A maior 
dificuldade depois de sua criação será mantê-lo atualizado, pois novas ativi- 


dades terão que ser absorvidas e executadas continuamente. O processo de 


129 


ITIL - GUIA DE IMPLANTAÇÃO 


gestão de configuração, como observamos neste capítulo, visa produzir um 
importante elemento de apoio para os demais processos. Podemos até dizer 
que ele, por si só, não interfere diretamente na qualidade dos serviços ofe- 
recidos pela TI, mas, sem dúvida, sua ausência causa impactos. Esta é uma 
característica dos processos “meio” quando comparados aos processos “fim” 
(tais como a gestão de incidentes). 

Justamente por não ser um processo-fim, muitas vezes seus resultados são 
pouco visíveis se analisados isoladamente. Para que possamos assegurar que 
os recursos necessários para execução do processo de gestão de configuração 
continuem a estar disponíveis, e que os envolvidos continuem engajados, 
devemos então demonstrar que a presença do CMDB está agregando bene- 
fícios para os demais processos. 

Procure identificar em quais processos o CMDB realmente está sendo 
aplicado e demonstre como estes processos teriam que operar sem a presença 
do CMDB. As deficiências geradas pela ausência ou os benefícios pela pre- 
sença poderão, então, servir de justificativa para a manutenção das iniciativas 
e esforços. 

Algumas empresas, após terem vencido as resistências iniciais da falta de 
recursos, de ferramentas e processos para executar a gestão de configuração, 
falham por não conseguir demonstrar seus benefícios. Outras empresas tam- 
bém falham por demonstrarem os resultados tarde demais. Este é um cuida- 
do adicional que se tem de tomar: procurar apresentar resultados no tempo 
adequado. Muitas vezes, os resultados até já estão presentes no ambiente da 
GSTI, mas por não estarem sendo divulgados geram descrença no processo 
fazendo com que sua real importância não seja percebida. 

Para manter também as coisas funcionando invista tempo e recursos na 
execução desta atividade. Não acredite em fórmulas milagrosas de softwares 
de discovery que irão lhe fornecer todo o controle necessário. Invista em pro- 
cessos de gestão de configuração associados aos demais processos, principal- 
mente aos processos de mudança e liberação. Nenhuma mudança nos itens 
de configuração pode ocorrer sem que isso seja refletido em seu CMDB, 
previamente. No instante em que uma ferramenta de discovery apontar uma 


alteração de características já será muito tarde... 
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Se hoje você não tem alguém alocado à função de manutenção e atua- 
lização do seu CMDB de modo sistemático e diário, então repense seus 
processos. Se muita coisa muda diariamente então sua atualização também 
deve ser diária. A ideia de mensalmente, trimestralmente, semestralmente 
ou até anualmente fazer levantamentos criará a falsa impressão de que você 
tem algum tipo de controle, mas, na verdade, efetivamente o controle preciso 
não existirá. Se todos os processos que manipulam itens de configuração não 
mantiverem íntima relação com o processo de gestão de configuração, em 
pouco tempo todo o esforço alocado na criação de seu CMDB poderá ser 


perdido. 


LIÇÕES APRENDIDAS: Lembre-se de que pequenas atividades da gestão de con- 
figuração deverão fazer parte do dia a dia das equipes que se envolvem com a 
gestão de incidentes, de liberação, de mudanças etc. O sucesso da gestão de 
configuração dependerá muito mais dos demais processos do que dela mesmo. 
Faça uma matriz RACI e descubra quem executa cada atividade da gestão de 
configuração. Depois, atribua estas atividades e controle suas execuções. 
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Preparar a empresa para a GSTI 
Preparar a TI para a GSTI 
Construir um CMDB 


Construir um Catálogo de Serviços 


Construir Acordos de Nível de Serviço 


Construir uma Base de Conhecimento 


Implantar processos operacionais 


D ando sequência ao nosso conjunto de artefatos essenciais para a im- 
plantação de uma GSTI iremos abordar o catálogo de serviços. Muitas 
pessoas poderiam até defender a ideia de que até antes da criação de um 
CMDB deveríamos definir o catálogo de serviços. Não estariam, de certo 
modo, erradas. Acredito que, neste caso, estaríamos também discutindo um 
velho dilema: devemos atuar de modo bottom-up ou top-down? 

Aqueles que primeiro definem e constroem um CMDB estarão dando um 
enfoque bottom-up, ou seja, primeiro identificando os elementos básicos que 
serão agregados para produzir os serviços para, então, chegar ao mapeamen- 
to dos serviços. Já aqueles que definem primeiro seu catálogo de serviços para 
depois detalhá-lo tecnicamente, produzindo dados para o CMDB, estarão 
dando um enfoque t0p-down. Qual é a melhor abordagem? Difícil respon- 
der. O importante, entretanto, é que ao final tanto do processo bottom-up 
como do top-down tenhamos estes dois artefatos integrados. 

Não adiantará termos um CMDB extremamente detalhado se não utili- 
zarmos estes dados para associá-los aos serviços que eles produzem. Tam- 
bém não adiantará ter um catálogo de serviços abrangente e completo sem 
que ele tenha dados dos itens de configuração que estão associados a estes 
serviços. Um, efetivamente, complementa o outro produzindo uma visão do 
que é oferecido e como é oferecido. 

Um motivo que pode levar muitos a começarem pelo catálogo de servi- 
ços é que, em princípio, ele é mais fácil de ser produzido. Pensando então 
naquela máxima da ITIL® de que devemos buscar sucessivas melhorias con- 
tínuas, poderíamos produzir um catálogo de serviços inicial sem vinculá-lo a 
nenhum dado específico do CMDB (deixando para produzir o catálogo téc- 
nico de serviços mais tarde) para apenas posteriormente construir o CMDB 


e completar uma nova fase de melhoria no catálogo de serviços. Essa pode 
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ser uma abordagem adequada, desde que o processo de complementação do 
catálogo de serviços inicialmente criado aconteça. 

Em muitos casos, o que acaba acontecendo é que, depois de criado o ca- 
tálogo inicial, encerra-se o processo e a criação do CMDB e sua associação 
ao catálogo nunca acontecem, pois são tarefas mais complexas e geradoras 
de demanda de recursos. Neste caso poderia, então, ter sido mais prudente 
começar com uma abordagem bottom-up que garantisse que primeiro uma 
base de dados de referência fosse criada para só então ser viabilizada a criação 
do catálogo de serviços. 

Também aqueles que começam pelo CMDB devem ter o cuidado de não 
investir muito tempo nesta atividade, deixando o processo de criação do ca- 
tálogo de serviços para ser executado muito tardiamente. Sem um catálogo 
criado, outros artefatos, como os acordos de nível de serviço, também estarão 
impedidos de serem criados. Portanto, um catálogo elaborado antes pode 
liberar a execução de outras atividades importantes em paralelo. 

Havendo condições de conduzir as duas abordagens simultaneamente 
(bottom-up combinado com top-down), poderemos ter uma combinação que 
irá gerar melhores resultados. Enquanto uma equipe poderia trabalhar na 
produção de um catálogo de serviços, outra poderia trabalhar na construção 
de um CMDB, ou então, para cada serviço incluído no catálogo de serviços, 
a mesma equipe poderia buscar os itens de configuração que o compõem, 
preenchendo o CMDB. É claro que nesta situação iremos encontrar muitos 
serviços que compartilham os mesmos itens de configuração e deveremos 


tomar o cuidado para não gerar redundâncias no CMDB. 


LIÇÕES APRENDIDAS: Independentemente de escolher a abordagem top-down 
ou bottom-up procure durante a construção de seu catálogo de serviços mesclar 
visões do catálogo técnico e do catálogo de negócios para que ele sirva tanto 
para o uso da TI como para o uso das áreas de negócio. 
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TODOS CONHECEM REALMENTE O QUE É UM SERVIÇO? 


Vamos agora abordar um fato muito preocupante: muitas pessoas se 
propõem a criar um catálogo de serviços, mas não compreenderam ainda 
exatamente o que ele é. Existem, inclusive, livros no mercado apresentando 
conceitos e exemplos de catálogos de serviços de modo equivocado, levando 
pessoas a acreditar em falsas ideias. 

Um catálogo de serviços é um artefato produzido pela reunião de infor- 
mações sobre os serviços, certo? É aí que começa a confusão, pois muitas 
pessoas, apesar de saberem o conceito da ITILº para serviço, ao criarem um 
catálogo o deixam de lado. Se este conceito essencial não for transmitido e 
assimilado por todos os envolvidos no processo de GS TI, correremos o risco 
de comprometer seriamente os resultados esperados. Para evitar falhas, basta 


lembrar-se do conceito básico de serviço apresentado na ITIL®: 


SERVIÇO: Um conjunto de elementos (software, hardware, processos, pessoas, 
tecnologias, documentos etc.) inter-relacionados de modo a prover as facilidades 
necessárias para a execução de uma atividade de negócio, entregue aos clientes 
e usuários sem que eles tenham que se responsabilizar pela infraestrutura e pelos 
custos de sua implantação e operação. 


Se esta definição de serviço for aceita, então podemos falar em avaliar a 
capacidade de um serviço, medir a disponibilidade de um serviço, elaborar 
um plano de continuidade para um serviço, prover meios para restabelecer 
um serviço interrompido, avaliar problemas que impactam um serviço, de- 
finir aspectos financeiros associados ao custo de provimento de um serviço, 
analisar riscos associados aos ambientes dos serviços e tantos outros temas 
que a ITIL® trata com total propriedade. 

Para saber se um item que você pretende incluir em seu catálogo é real- 
mente um serviço (pois, se não for, não deveria estar lá), basta então respon- 
der a algumas simples perguntas: 
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Este item que imagino ser um serviço: 


Pode ter um tempo de disponibilidade acordado? (G. Nível Serviço) 
Pode se tornar indisponível por um incidente? (G. Incidentes) 


Precisa ser restaurado o mais breve possível quando for interrompido? 
(G. Incidentes) 


Tem um conjunto de usuários que o utilizam e um cliente que o requisi- 


tou? (G. Nível Serviço) 
Tem um requisito de capacidade para sua utilização? (G. Capacidade) 


Tem um custo de implantação e operação e pode ser controlado? (G. 


Financeira) 


Tem um conjunto de itens de configuração que o compõem? (G. Con- 
figuração) 


Pode ter um contrato de nível de serviço estabelecido e negociado? (G. 
Nível Serviço) 


Entre outras... 


Vamos ver um item e verificar se ele é um serviço que poderia ser incluído 


em nosso catálogo, por exemplo, o serviço de correio eletrônico. 


Perguntamos, então: “O serviço de correio eletrônico...” 


Pode ter um tempo de disponibilidade acordado? Sim, de 90% de dispo- 
nibilidade em horário comercial, cinco dias por semana, com interrupções 
de no máximo 30 minutos em cada evento de parada. 


Pode se tornar indisponível por um incidente? Sim, caso uma caixa postal 
de armazenamento de mensagens seja perdida, o serviço de correio ele- 
trônico para um dado usuário pode ser interrompido. 
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Precisa ser restaurado o mais breve possível quando for interrompido? 
Sim, para garantir que o usuário do serviço de correio eletrônico não 
tenha sua atividade de negócio afetada, o serviço precisa ser restaura- 
do rapidamente. 


Tem um conjunto de usuários que o utilizam e um cliente que o re- 
quisitou? Sim, vários usuários do departamento de RH necessitam do 
correio eletrônico para executar suas atividades diárias, e a unidade de 
negócio RH, representada por seu gerente, requisitou que o serviço 
fosse disponibilizado para todos os seus funcionários, pois sem este 
serviço a atividade de seu departamento seria comprometida pela falta 
de meios para comunicação. 


Tem um requisito de capacidade para sua utilização? Sim, foi estabele- 
cido que a TI deverá ter uma capacidade de atender até 3 mil mensa- 
gens diárias, para pelo menos 100 diferentes contas de e-mail, deven- 


do manter um histórico de mensagens de pelo menos cinco anos. 


Tem um custo de implantação e operação e pode ser controlado? 
Sim, os custos fixos e variáveis deste serviço foram aprovados no or- 
çamento anual e estão sendo acompanhados mensalmente através 
da contabilização do uso de espaço em disco, mão de obra alocada 
etc. 


Tem um conjunto de itens de configuração que o compõem? Sim, o 
serviço de correio eletrônico utiliza o servidor de dados XPTO-1, roda 
com Ms-Exchange e Ms-Outlook em 100 diferentes estações de traba- 
lho, todas conhecidas e cadastradas. 


Pode ter um contrato de nível de serviço estabelecido e negociado? 
Sim, um contrato de SLA foi definido estabelecendo que este serviço 
deva estar disponível 90% do tempo em horário comercial, cinco dias 
por semana, tendo suporte garantido inclusive nos meses de férias 
coletivas, capacidade de atendimento de 100 diferentes contas de 
e-mail etc. 
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Com todas estas características podemos demonstrar que inserir o serviço 


“correio eletrônico” em nosso catálogo de serviços está plenamente compa- 


tível com o conceito ITIL® estabelecido. Porém, veja a seguir alguns exem- 


plos de itens que são comumente citados como de um catálogo de serviços, 


inclusive em livros e apostilas: 


e Criação de conta de e-mail. 


e Atualização de software aplicativo. 


e Instalação de impressora. 


Entre outros... 


Nenhum destes passaria no teste das perguntas de qualificação de servi- 


ços. Pegue o primeiro deles e valide: “Uma criação de conta de e-mail.” 


Perguntaremos, então: “Uma criação de conta de e-mail...” 


Pode ter um tempo de disponibilidade acordado? Não. Quem tem a dispo- 
nibilidade acordada é o serviço de correio eletrônico. A criação de conta 
de e-mail pode até ter um prazo para ser executada, mas isto não significa 
que possamos definir uma disponibilidade para a criação de uma conta 
de e-mail. 


Pode se tornar indisponível por um incidente? Não. A criação de conta 
não fica indisponível. Quem fica indisponível é o serviço de correio ele- 


trônico. 


Precisa ser restaurado o mais em breve possível quando for interrompido? 
Não. A criação de conta não é restaurada. Quem é restaurado é o serviço 
de correio eletrônico que ficou fora do ar. 


Tem um conjunto de usuários que o utilizam e um cliente que o requisitou? 
Não. O correio eletrônico é que tem usuário. A criação de contas não tem 
usuários. 
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E assim por diante. 


Nenhuma das perguntas poderá ser validada para a “criação de conta de 
e-mail”, nem para a “instalação de impressora”, nem para a “atualização de 
software aplicativo”. Estes itens não são serviços da TI. São tarefas executa- 
das para operacionalizar serviços de TI. 

O serviço “correio eletrônico” tem tarefas executadas pela TI, que podem 


» «& 


ser “criação de conta”, “compactação de pasta”, “recuperação de backup de 


» « 


pasta”, “exclusão de conta” e assim por diante. Mas quantas coleções de tare- 
fas vemos por aí sendo chamadas de catálogo de serviços? Muitas. 

Não se trata de interpretação, como alguns dizem. Estamos falando da 
validação de um item de um catálogo de serviços contra os conceitos da 
ITILS. Se você testar os itens de seu catálogo de serviços e nenhum deles 
passar na “prova” das perguntas anteriores, então provavelmente você não 
criou um catálogo de serviços, mas sim uma lista de tarefas executadas. 

Outro conceito essencial precisa ser também relembrado: serviços não são 
executados pela TI. Serviços são entregues pela TI. Se você executa uma 
“criação de conta de e-mail”, então isto é tarefa. Se você entrega o “correio 


eletrônico” para ser usado pelo departamento de RH, então isso é um serviço 


da TI. 


TAREFA: 


CORREIO ELETRÔNICO 


— CRIAR CONTA DE E-MAIL 
— AUMENTAR COTA E-MAIL 


Catálogo de serviços Catálogo de tarefas 


Acredito que parte desta confusão seja também causada, de certo modo, 
pela própria ITILº, que não apresentou ainda claramente o conceito de “ta- 


refas” associadas a serviços, nem na V2 nem na V3. Talvez, se pudéssemos 
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ter formalmente criado um catálogo de tarefas associado ao catálogo de 
serviços, todas as dúvidas fossem esclarecidas. Algo parecido até existe no 
processo de gestão de liberação, mas como não há muito aprofundamento 
nos cursos de ITIL Foundationsº, cria-se a confusão. Procure sempre es- 
tabelecer este conceito básico no começo de cada projeto de implantação 
de GSTI. 

No capítulo seguinte veremos também que a confusão continua quando 
se fala de acordos de nível de serviço, ou SLA. Muita gente ainda acredita 
que definir que uma tarefa de “instalação de impressora” será feita em até 
duas horas é definir um nível de serviço. Isto é somente parte da verdade, 
mas o conceito de SLA é muito mais abrangente e merece atenção. Fique, 
portanto, atento no início de qualquer projeto de implantação de GSTI para 
que os conceitos estejam muito claros entre todos os envolvidos dos níveis 
gerenciais e operacionais. Pode parecer que todo mundo está falando a mes- 
ma língua, mas, no fundo, apesar de as palavras serem as mesmas, os concei- 
tos por trás de cada uma podem ser bem diferentes na cabeça de cada um, e, 


com isso, o resultado final pode ser bastante comprometido. 


LIÇÕES APRENDIDAS: Fique atento para criar um catálogo dos serviços que a TI 
entrega aos clientes e não um catálogo das tarefas que a TI executa para os clien- 
tes. Depois de criado o catálogo de serviços, você poderá identificar tarefas que 
executa para cada um deles. Diferencie tarefas de serviços! 


QUEM SERÁ O BENEFICIADO COM O CATÁLOGO DE SERVIÇO? 


Outra questão que precisa estar bastante clara desde o início de nosso pro- 
jeto de GSTI, quando se fala em criar e manter um catálogo de serviços, é o 
objetivo deste catálogo, ou para que ele está sendo criado. Não se trata só de 
formalismo ou de padronização, como muitos acreditam, mas de, mais uma 
vez como fizemos no processo de gestão de configuração, “mapear o terreno” 


no qual iremos atuar. 
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Se estamos buscando a gestão de serviços de TI, então é claro que preci- 
samos conhecer os serviços que iremos gerenciar, certo? Porém, lembre-se 
dos exemplos de itens que compõem o catálogo de serviços que demos no 
tópico anterior: tem gente por aí gerindo os serviços errados. Tem gente 
acreditando que deve gerenciar se a “instalação de impressora” está sendo 
bem feita, mas não está gerenciando se o serviço de impressão centralizada 
está atendendo às demandas da empresa. 

Alguns continuam a gerenciar o service desk como um help desk em que 
era mais importante saber se as tarefas eram bem desempenhadas do que 
perguntar ao cliente se o resultado obtido com o serviço utilizado atendia às 
expectativas dele. Lembre-se de que esta cultura deve mudar. 

Deste modo, parece óbvio que o primeiro beneficiado com o catálogo 
de serviços deva ser a própria TI, pois terá um elemento que demonstrará 
quais são os serviços que ela deve gerenciar. Mas o que é gerenciar? Segundo 
o dicionário Michaelis, é o ato de administrar ou dirigir. Portanto, precisamos 


administrar e dirigir os serviços que produzimos e entregamos para serem usados 


pelos nossos clientes e, para isso, temos que conhecê-los. 


Catálogo de serviços Catálogo de tarefas 


Serviços a serem gerenciados Tarefas a serem oferecidas 
pela TI aos clientes 


Em segundo lugar, outro grande beneficiado com a existência de um ca- 
tálogo de serviços é o cliente. Não, como dizem muitos por aí, para que ele 
saiba quais serviços a TI irá executar (sic), mas sim para que ele saiba quais 
serviços a TI pode disponibilizar para que sua área de negócios aplique na 
consecução de suas atividades. 

Imagine o caso de uma grande empresa que tenha criado uma nova dire- 
toria de assuntos estratégicos. Esta era uma área que até hoje não existia na 


empresa e a alta direção resolveu convidar um diretor externo que conhecesse 
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sobre o assunto para assumi-la. Esta pessoa, depois de contratada, chegou à 
empresa e na primeira reunião de trabalho apresentou o modelo de operação 
de sua área, elencando todas as atividades que a área deveria desempenhar. 
De imediato, solicitou para a área de TI da empresa uma lista dos serviços 
que a TI oferecia para poder verificar quais serviços poderiam ser agregados 
como facilitadores para execução de suas atividades, chegando a uma lista 


parecida com: 


TABELA 1 
Quantidade 
Serviço oferecido pela TI Processo de negócio de usuários 
Correio eletrônico Comunicação com o mercado 10 
Acesso à internet Pesquisa de mercado 5 
Armazenamento de dados Pesquisa de mercado 10 
Planejamento 2 
Solução de gestão corporativa | Planejamento 2 
Comunicação com o mercado 10 
Pesquisa de mercado 10 


E assim por diante... 


Este exemplo demonstra como é essencial para nossos clientes identifi- 
carem quais são os serviços oferecidos pela TI, quais suas características, sua 
disponibilidade, sua capacidade, seu modo de suporte etc. Neste instante, 
pouco interessa se “criamos novas contas de acesso à internet”, se “tiramos 
dúvidas de internet” ou que outras tarefas somos capazes de realizar para o 
serviço “acesso à internet”. 

O cliente precisa saber se sua área terá ou não este serviço disponível 
para poder cumprir com seus objetivos de negócio. Se o cliente detectar que 
requer um serviço, baseado talvez até num conhecimento prévio de outra rea- 
lidade em outra empresa onde trabalhou, mas que não está sendo atualmen- 
te oferecido pela TI, então ele poderá claramente indicar a necessidade de 
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disponibilização deste novo serviço, seja com recursos providos pela própria 
TI ou pela contratação externa (modelo de uso as a service). 

Por falar em as a service, parece que a cada dia fica mais fácil tentarmos 
identificar o que realmente é um serviço se nos basearmos no conceito de 
ofertas as a service que vemos no mercado. Começamos esta era pelo software 
as a service e hoje temos várias outras ofertas desse tipo. Vemos que tudo que 
é vendido as a service é efetivamente um “service”. 

Quando a TI adquire um software de gestão de folha de pagamento as a 
service está na verdade oferecendo para sua empresa um serviço de TI capaz de 
atender ao processo de gestão de folha de pagamento. Logo, nesta empresa a 
TI oferecerá mais um serviço: um ambiente de Gestão de Folha de pagamento, 
composto por software, hardware, comunicação, processos, pessoal de suporte 
etc., tudo encapsulado na visão de um serviço. Mas e todos os demais serviços 
oferecidos, mesmo com recursos internos, também não deveriam ser vistos 
assim por nossos clientes de TT? É claro que sim. É o que a ITIL® defende 
quando diz que um serviço é um conjunto de elementos que serão agregados 
para prover uma facilidade para uma área de negócio sem que ela tenha que se 
preocupar com custos e riscos de operação deste serviço. 

Já destacamos a importância do catálogo de serviços para a TI e para os 
clientes da TI. Vamos agora abordar os demais envolvidos num processo de 
gestão de serviços de TI: os provedores de serviços internos e externos (os 
fornecedores). Também para eles a existência de um catálogo de serviços de 
TI será bastante importante. O nível de abstração que o catálogo oferece 
permite que, por exemplo, um fornecedor externo saiba que está sendo re- 
quisitado a fornecer recursos para transmissão de dados para um serviço de 


“agendamento de visitas técnicas” utilizado pelo departamento de vendas. 


Linguagem de programação 
| 
Serviço de 


Fornecedor E Agendamento Ambiente de banco de dados 
o 


Técnicas 
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O fornecedor não precisa saber se “agendamento de visitas” é um sistema, 
um módulo ou um programa. Também não precisa saber se roda via web ou 
não. Nem se foi construído em VB, Delphi ou Java. Ele só precisa saber que 
existe um serviço, que este serviço atende a uma capacidade de negócio, que 
teve sua capacidade de recursos definidas, e que, em função disso, o fornece- 
dor deverá prover um link de velocidade X ou Y. 

Não estamos mais falando de sistemas ou aplicações. Estamos agora fa- 
lando de serviços, e se o fornecedor for capaz de conversar nesta linguagem, 
também nos oferecerá um “serviço de transmissão de dados” sem ter que nos 
“importunar” com detalhes técnicos sobre qual é a tecnologia que ele ofere- 
ce, qual é o tipo de antena que usa, qual é o fabricante com o qual mantém 
parcerias etc. Se pudermos definir a disponibilidade, capacidade, segurança, 
e outras características do nível de serviço desejado para este fornecedor, e ele 
puder nos atender nestes requisitos, o resto será risco e custo dele. 

Perceba que esta visão baseada em serviços influenciará desde a fase de 
estratégia do serviço, passando pelo seu desenho, sua transição e operação. 
Estaremos construindo e operando novos serviços baseados talvez na agre- 
gação de serviços de terceiros, tudo num patamar de abstração muito maior 
e principalmente com garantias de nível de serviço e não de marcas, mode- 
los, fabricantes. Pode ser um longo caminho a ser trilhado até se chegar a 
tal nível de maturidade, mas usando-se a abordagem da melhoria contínua 
devemos pensar que hoje talvez seja o dia para dar o primeiro passo nesta 
direção, estabelecendo conceitos de serviços entre as partes envolvidas nos 


projetos. 


LIÇÕES APRENDIDAS: Use o catálogo de serviços como um elemento de agre- 
gação entre as áreas clientes e a TI. Estabeleça um conceito de “orientação a 
serviços” dentro e fora da TI. A orientação a serviços (service oriented) não é uma 
tecnologia, mas sim uma modalidade de atuação: um modo de fornecer e receber 
facilidades para a operação de uma área de negócio. 
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QUAL A DIFERENÇA ENTRE CATÁLOGO E DIRETÓRIO? 


Muitas empresas, já cientes da necessidade de um catálogo de serviços, 
procuram criá-lo no começo de seus projetos. Considerando que não criem 
um catálogo de tarefas que a TI executa, teremos então realmente um catá- 
logo de serviços, certo? Também não. O que às vezes encontramos são o que 
poderíamos chamar de diretórios de serviços. São coleções de nomes de ser- 
viços, às vezes agrupados em hierarquias, mas que não agregam muitos dados 
efetivos sobre os serviços que ali são representados. São a estrutura esquemá- 


tica de um futuro catálogo de serviços ou o “esqueleto” desse catálogo. 


Serviços básicos 


Diretório de serviços Catálogo de serviços 


Esta estrutura de diretório de serviços, se bem elaborada, é realmente um 
bom começo para um catálogo. Podemos dizer até que é o primeiro passo 
importante na construção do catálogo, como vamos ver no próximo tópico. 
Porém, devemos ter especial atenção para que a preocupação com o catálogo 
de serviços não se encerre depois que se tenha um diretório criado. Esta tem 
sido a principal falha em vários projetos: as pessoas entendem que preci- 
sam construir um catálogo, alocam pessoas para pensar em sua estrutura, 
fazem levantamentos, criam um diretório de serviços e fim. Sim! Pensam 


que acabaram sua atividade ao chegar ao diretório de serviços, publicando-o 
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ou inserindo-o numa tabela em seus sistemas de gestão de atendimento. In- 
felizmente, temos uma má notícia: neste instante, seus “problemas” estão só 
começando, pois ainda resta muita coisa a ser feita. 

Às vezes, parece que muitas pessoas estão mais preocupadas em ter este 
diretório de serviços, não porque realmente o acham importante para a 
GSTI, mas porque o software de registro de solicitações que vão usar no 
service desk precisa desta tabela para poder registrar um chamado. Pare- 
ce até que se o software não exigisse esta tabela, talvez estas pessoas nem 
“perderiam tempo” criando este tal “catálogo de serviços” (na verdade, um 
diretório). É como se a criação do suposto catálogo de serviços fosse uma 


etapa de definição de tabelas internas necessárias para a parametrização de 


um sistema de service desk. 


Descrição: 


Já vimos, porém, que existem vários outros benefícios associados à exis- 
tência do catálogo. Ter uma tabela para inserir no sistema de gerenciamento 
de chamados deve ser uma consequência e não um objetivo. Quando todos 
os envolvidos no projeto perceberem isso, teremos a devida importância es- 


tabelecida para as tarefas de criação e manutenção do catálogo. 


LIÇÕES APRENDIDAS: Não substitua um catálogo de serviços por um diretório 
de serviços, pois mesmo o mais simples dos catálogos deve conter muito mais 
informação do que um complexo diretório. 


148 


COMO IMPLANTAR E MANTER UM CATÁLOGO DE SERVIÇOS DE TI? 


COMO CRIAR UM CATÁLOGO DE SERVIÇOS? 


Existem várias abordagens possíveis para se criar um catálogo, mas em 
todas elas o mais importante, antes de tudo, é ter certeza de que todos en- 
tenderam o que é um serviço. 

Até mesmo aqueles que pensam em começar com uma lista de tarefas que 
a TI executa para seus clientes podem, ao final, chegar a uma lista de serviços 
se tiverem a distinção entre tarefas e serviço. Em um projeto no qual parti- 
cipamos certa vez, utilizamos esta abordagem. Solicitamos para cada técnico 
da equipe que enumerasse uma lista de todas as tarefas que ele executava em 
seu dia a dia. Pedimos também que indicasse a frequência com que a execu- 
tava (se diariamente, semanalmente, mensalmente ou eventualmente) e se 
já existia um procedimento documentado de como era tal execução. Nosso 
objetivo principal não era efetivamente construir um catálogo de serviços, 
mas sim identificar o nível de complexidade de procedimentos existentes, 
de variedade de ações, de concentração de atividades por período etc. Po- 
rém, conseguimos uma lista de tarefas que nos mostravam para quais serviços 
eram executadas e daí pudemos derivar uma lista de serviços existentes. 

Assim, por exemplo: “Criar conta de e-mail”, “recuperar pasta de e-mails”, 
“aumentar tamanho da caixa de e-mails” etc., nos fez identificar que existia 
um serviço denominado “correio eletrônico” sendo oferecido pela TI. É claro 
que este processo não é um processo 100% seguro. Muitos fazem algo pare- 
cido com isso e acabam por criar um catálogo de tarefas agregadas por ser- 
viços e chamam isso de catálogo de serviços. Aí ocorre então uma distorção 


de conceitos perigosa. 


Criar conta de e-mail 


Correio 
Eletrônico 


Recuperar pasta de e-mail 


Aumentar tamanho da caixa 


Lista de tarefas Serviços 
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Neste projeto, também tínhamos feito outro levantamento com outra fi- 
nalidade que nos permitiu refinar a lista de serviços. Havíamos solicitado, 
através de um formulário, que cada área de negócio da empresa indicasse que 
tipo de “recurso” fornecido pela TI eles utilizavam em suas atividades diárias. 
Explicamos que recursos poderiam ser sistemas, softwares, equipamentos, 
documentos etc. Eles também deveriam indicar com que grau de frequên- 
cia utilizavam, quantas pessoas do departamento o usavam, em que dias e 
horários eram usados etc. Nosso objetivo era mapear critérios de utilização 
visando estabelecer prioridades, disponibilidade, capacidade etc. Novamen- 
te, pudemos identificar uma lista de serviços, pois quando alguém dizia que 
utilizava “a impressora central do departamento todo dia, das 8h até as 18h”, 
nós podíamos entender que o serviço “impressão centralizada” era um item 
do catálogo de serviços oferecido a este cliente. 

Em outras situações, o processo utilizado é simplesmente fazer um 
brainstorming com o próprio pessoal da TI solicitando que eles enumerem 
quais são os serviços “que lembram” que a TI fornece hoje para a organiza- 
ção. Normalmente, esta lista acaba ficando bem completa, principalmente 
imaginando que existam pessoas mais “antigas” trabalhando na equipe de TI 
e que elas tenham uma visão ampla da atuação da TI. 

Combinado a este processo, podemos utilizar listas predefinidas de ser- 
viços já conhecidos e tipicamente oferecidos em outras organizações para 
que as pessoas se lembrem de outros serviços que já estão sendo fornecidos. 
Podemos também combinar estas estratégias acima expostas entre si, reco- 
lhendo listas de tarefas, listas de recursos utilizados pelos clientes, listas de 
serviços predefinidos e listas produzidas por um brainstorming. 

Finalizada, então, toda a etapa de coleta de nomes de serviços, teremos 
nosso “esqueleto”, ou nosso diretório de serviços oferecidos. A lista, a partir 
desse momento, irá requerer a agregação de dados adicionais importantes 
para se transformar em um catálogo de serviços. Precisaremos acrescentar 
informações sobre características técnicas do serviço (catálogo técnico) e so- 
bre características de uso dos serviços (catálogo de negócio), além de outros 
dados sobre modos de uso, condições de suporte, provedores do serviço, cus- 


tos, restrições de uso, e também, não menos importante, uma lista de tarefas 
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executadas pela TI para cada serviço. É certo que alguns destes conteúdos 
poderão ser agregados pelo processo de gestão de nível de serviço, que vere- 
mos no próximo capítulo, mas as informações que o processo irá agregar de- 
verão ter como “repositório” o próprio catálogo de serviços, demonstrando, 
na prática, a integração entre os processos de gestão de catálogo e gestão de 


nível de serviço. 


Diretório de one . 
serviços Catálogo 
+ = técnico 


A habilidade em aplicar um ou outro processo de coleta de informações, 


de sintetizar uma lista de serviços, de definir os tempos para complementa- 
ção das informações necessárias aos serviços e tantos outros pontos só poderá 
ser obtida com a prática. Como já dissemos, não existe um guia infalível ou 
uma “receita de bolo” que se aplique a todas as empresas e a todos os pro- 
jetos. A maturidade das empresas, a receptividade ao processo, as fontes de 
informação, a confiabilidade das fontes e até o tempo disponível para execu- 
tar esta atividade poderão ser fatores que afetarão a escolha da abordagem a 
ser aplicada. O que é importante não é “como será feito”, mas sim “para que 
será feito”. 

Todos sabemos aonde precisamos chegar e o que devemos obter ao fi- 
nal. Criar o caminho poderá depender de maior ou menor experiência neste 
ambiente. Se você não tem ainda esta experiência, busque ajuda com quem 
já tem e não tente copiar catálogos de outras empresas ou da web. Existem 
centenas ou talvez milhares de pessoas perguntando em inúmeros fóruns na 
web: “Você teria um modelo de catálogo de serviço para me fornecer?” Per- 
ceba que nem nos livros oficiais da ITIL® existem modelos claros de catálo- 


gos. Se consultar um modelo fosse uma boa prática, por que a própria ITILº 
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não colocaria lá então estes modelos nos seus próprios livros? Esquecimento? 
Falta de espaço? Com certeza, não. Vamos falar mais à frente sobre modelos 


de catálogos. Aguarde. 


LIÇÕES APRENDIDAS: Existem vários métodos possíveis para você identificar os 
serviços que a TI oferece. No final, todos devem levar, com menos ou mais tra- 
balho, à produção do mesmo artefato. Não interessa o método que você utilize, 
se uma organização é atendida por uma mesma estrutura de TI, haverá sempre 
um catálogo de serviços inerente deste ambiente. O catálogo está personificado 
pelos próprios serviços em uso, investigue-os e irá descobri-los. 


COMO MANTER UM CATÁLOGO DE SERVIÇOS? 


Vamos então considerar que, após aplicar um ou mais métodos para obter 
seu catálogo de serviços, você tenha finalmente chegado lá. Temos outra má 
notícia: seus “problemas” estão só começando. Mesmo antes de ter termi- 
nado a criação de seu catálogo, ou até pior, mesmo antes de ter começado a 
elaborá-lo, você deveria já ter previsto um conjunto de iniciativas que garan- 
tam que ele continuará atualizado no curto, médio ou longo prazos. 

Por exemplo, se você definiu que iria utilizar um formulário para captar 
informações junto aos técnicos e aos clientes (tal como falamos anteriormen- 
te), é essencial que você diga a eles que eles deverão preencher o tal formulá- 
rio, mas que precisarão manter uma cópia destas informações em seu poder 
e que, a cada mudança que percebam no seu dia a dia, deverão atualizar o 
formulário e reenviar à TI. A TI, por sua vez, se depois de passado certo pe- 
ríodo não receber nenhuma atualização de uma área, deverá promover uma 
“revisão” dos dados recebidos através de um novo levantamento ou de solici- 


tações de confirmação. 
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Assim como já dissemos no capítulo da gestão de configuração, pior do 
que não ter um CMDB é ter um CMDB desatualizado. Também com rela- 
ção ao catálogo de serviços, esta afirmação é verdadeira: pior do que não ter 
um catálogo de serviços é ter um catálogo desatualizado. 

Usando uma analogia, considere que o catálogo é seu mapa de bordo. 
Quem não tem um mapa em mãos irá seguir “perguntando de esquina em 
esquina”, mas chegará ao seu destino. Já quem tem um mapa desatualizado, 
irá confiar neste mapa e, sem perguntar a ninguém, irá seguir suas orienta- 
ções chegando, talvez, ao destino errado. 

E quando seu catálogo começará a ficar desatualizado? Da mesma for- 
ma como no caso do CMDB, tudo fica desatualizado a partir do momento 
em que é documentado e não recebe mais feedback de mudanças ocorri- 
das. Podemos ter um catálogo de serviços desatualizado no dia seguinte do 
levantamento feito no primeiro departamento de nossa empresa. Podemos 
não ter concluído nem 10% do escopo de criação de nosso catálogo e ele já 
estar desatualizado. Não precisamos nem esperar ele ficar pronto. Ele ficará 


pronto hoje e já estará desatualizado há meses. 


D1 D2 D3 D4 D5... D n+1 
Criação 


Atualização 


Talvez seja por este motivo que tanto a criação de um CMDB como a 
criação de um catálogo de serviços não seja uma tarefa, mas sim um proces- 
so. À visão de processo demonstra que temos várias entradas, várias saídas, 
várias atividades, vários stakeholders, uma matriz RACI com responsabili- 
dades atribuídas, políticas, regras etc. Imaginar que a criação e manutenção 
de um catálogo vai se limitar a coletar dados ou a copiar um modelo é ignorar 


todo o processo que existe por detrás disso. 
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Felizmente, como novos serviços só serão criados, alterados e removidos 
com o controle da TI, será mais fácil manter o sincronismo entre o mapea- 
mento que possuímos e a realidade que está “lá fora”. Some-se a isso o fato 
de que vários processos ITILº têm algum tipo de vinculação com o catálogo 
de serviços, pois se referenciam aos serviços nele contidos e será mais fácil 
manter controle sobre sua sincronização. Assim, se este catálogo estiver de- 
satualizado, muito rapidamente algum destes processos irá detectar a falha. 
Por exemplo, o processo de gestão de incidentes, se executado corretamente, 
logo irá detectar que alguém está registrando um incidente ocorrido com um 
serviço, mas que os dados existentes no catálogo para este serviço não estão 
registrados ou estão desatualizados. 

Assim como o CMDB, o catálogo de serviços estará em frequente utiliza- 
ção pelos processos ITILº, permitindo que ele seja constantemente depura- 
do. Esta depuração, entretanto, é um processo passivo. Devemos prever um 
processo proativo de manutenção do catálogo. Para tanto, o próprio processo 
de gestão de catálogo de serviço deverá ser estruturado desde a fase inicial da 
concepção do catálogo. 

As mesmas fontes de informação que foram utilizadas para sua constru- 
ção inicial, ou seja, a busca de informações junto aos técnicos, junto às áreas 
usuárias etc. deverão continuar a ser monitoradas continuamente para iden- 
tificar mudanças não autorizadas. É claro que as mudanças que impactam o 
catálogo de serviços e que sejam consideradas mudanças controladas serão 
detectadas e tratadas pelo processo de gestão de mudanças caso ele este- 
ja ativo e executado adequadamente. Serviços criados, alterados, removidos 
etc. terão o feedback destas mudanças gerados pelo processo de gestão de 
mudanças, que as repassará para o processo de gestão de catálogo, que as 


registrará em definitivo, mantendo-o sincronizado. 


LIÇÕES APRENDIDAS: O catálogo de serviços não é só um produto de um proces- 
so. Ele é uma ferramenta de trabalho criada por um processo para ser usado em 


diversos outros. Use-o constantemente. 
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COMO DIVULGAR UM CATÁLOGO DE SERVIÇOS? 


A publicação ou divulgação do catálogo de serviços confunde-se muitas 
vezes com a própria noção de catálogo que muitas pessoas têm. Alguns 
acreditam que o catálogo de serviços deva ser um documento elaborado 
com um editor de textos, no qual todas as informações sobre o serviço 
devam ser transcritas. Outros acreditam que o catálogo de serviços deva 
ser uma planilha em que, em colunas distintas, cada informação deva ser 
armazenada. Para outros, ainda, o catálogo de serviços é uma tabela cadas- 
trada em seu sistema de registro de chamados que aparecerá nas telas como 
um item para ser selecionando na hora de criar chamados, isso se tudo 
estiver sendo bem feito. 

Aqui precisamos abrir um parêntese sobre a antiga diferença entre o help 
desk e o service desk. Um help desk tradicional não pode ser comparado com 
um service desk. Nunca! Não é uma questão de nomenclatura ou modismo 
como alguns podem declarar. O foco do antigo help desk era prestar ajuda 
aos usuários, seja instalando, configurando, removendo itens de software ou 
hardware. Já o service desk tem como função, segundo a ITIL®, restabelecer 
os serviços à sua operação normal o mais rapidamente possível, seja instalan- 
do, configurando ou removendo itens de software e hardware. O que muda, 
então, entre os dois ambientes? A visão do serviço envolvido! No help desk 
não interessava se existia ou não um serviço sendo impactado e, portanto, o 
catálogo era até desnecessário. Já no service desk nenhum chamado deveria 
ser registrado sem que o atendente claramente identificasse qual é o serviço 


que está sendo afetado. 


Dar suporte à tecnologia (TI) Dar suporte a serviços (SI) 
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Se seu usuário continuar a simplesmente dizer que precisa que seu 
“browser” seja configurado e se você continuar a registrar somente um cha- 
mado, dizendo que ele está associado ao “browser”, como você terá, ao final 
do mês, indicadores de qualidade de serviços? Esse chamado de “browser 
desconfigurado” será alocado como incidente de qual serviço? Seria do servi- 
ço de acesso à internet? Do serviço de intranet? Do serviço de gestão de folha 
de pagamento que usa o browser como ferramenta para acesso ao aplicativo 
de gestão de folha de pagamento que está “na nuvem”? Alguns destes? Todos 
estes? 

Vamos voltar e analisar o que a teoria diz sobre os incidentes: é a interrup- 
ção ou degradação de um serviço. Se alguém liga para registrar um incidente, 
você não deveria então questionar neste instante qual é o serviço afetado 
naquele momento? Pode ser que seu browser desconfigurado afete vários 
serviços, mas naquele momento em que você está abrindo uma solicitação 
no service desk, qual é o serviço que você não consegue utilizar por causa do 
browser desconfigurado? 

Um service desk de verdade não atua mais na “configuração de um 
browser” sem se preocupar em qual é o serviço que está sendo afetado por isso. 
Se o fizer, não terá nem como gerar indicadores de nível de serviço! Esta é 
outra falha! Tem gente gerando indicadores dentro da ITILº que sequer 
indicam a disponibilidade ou qualidade de um serviço. Continuam a mos- 
trar disponibilidade e qualidade de componentes de infraestrutura, mas não 
conseguem mostrar efetivamente quais serviços foram afetados num certo 
período de tempo. Isso contraria totalmente os conceitos da ITILº, pois a 
ideia é aprimorar a qualidade e disponibilidade de serviços e não de compo- 
nentes de infraestrutura. Quem tem um service desk e não usa o catálogo de 
serviços como elemento principal no registro de uma solicitação continua a 
ser um help desk dando suporte à infraestrutura. O termo service desk não 
significa, como alguns afirmam, uma central que executa serviços, mas uma 
central que atende a demandas associadas a serviços de um catálogo. 

Considerando-se, portanto, que a utilização do catálogo de serviço seja 


um requisito básico na operação diária de um service desk, há de se imaginar 
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que realmente ele deva estar representado dentro de uma tabela de um sis- 
tema de gestão de chamados. Isto não significa que também não deva estar 
num documento a ser distribuído aos novos clientes da TI, ou que não deva 
estar publicado numa página da intranet para consulta de visitantes (univer- 
sidades americanas publicam abertamente seus catálogos de serviços de TI, 
inclusive na web). 

Logo, o catálogo é um só se considerarmos seu conteúdo, mas poderá ter 
vários canais de divulgação e compartilhamento de informações. Seu conteú- 
do é essencial, não seu formato ou sua mídia de divulgação. Talvez até tenha- 
mos que ter diferentes formatos dependendo da mídia onde será acessado. 
Na sua intranet ele pode ter um formato de planilha, num documento a ser 
distribuído para os novos clientes da TI ele poderá ter um formato textual e 
no seu sistema de registro de chamados poderá ser uma simples lista de itens 
com algum tipo de tela de consulta a detalhes do item. 

Estes diferentes formatos são muitas vezes encontrados na web por pes- 
soas que procuram modelos a seguir. É importante que nestes casos se obser- 
ve o conteúdo que apresentam e o público ao qual se destinam. Não devem 
ser considerados “o catálogo”, mas “a publicação do conteúdo do catálogo”. 
Pela própria definição da TTILS, o catálogo é um repositório de dados sobre 
os serviços de TI oferecidos. O próprio termo repositório é algo bastante ge- 
nérico e abstrato. Não interessa onde as informações estão armazenadas, se 
são uma tabela, um texto, uma planilha, um banco de dados, ou partes de to- 
das essas mídias. Interessa, sim, o conteúdo que está lá coletado, preservado, 
atualizado e as mídias de publicação que conseguimos utilizar para divulgar 
toda esta informação. 


LIÇÕES APRENDIDAS: Não pense no catálogo como uma mídia. Pense no catá- 
logo de serviços como um conteúdo que pode ser publicado por várias mídias. 
Haverá sempre uma mídia mais apropriada para um determinado público-alvo e 
para uma atividade ou processo em questão. 
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Quando seu catálogo está terminado? 


Nunca. 

Muitas pessoas pensam que a elaboração de um catálogo de serviços é 
uma atividade com começo, meio e fim. Na verdade, é um processo, e, como 
todo processo, não tem começo, meio e fim. Processos têm, sim, entrada, 
processamento e saída, têm também realimentação das saídas para as en- 
tradas, e ainda um conjunto de atividades interdependentes e nem sempre 
sequenciais. Isso nos leva a assumir o fato de que podemos começar por 
diferentes entradas (como já mostramos), executar diferentes atividades em 
diferentes sequências, obtendo diferentes resultados em diferentes tempos, 
mas que, pela característica de realimentação existente neste processo, nunca 
teremos um catálogo de serviços final. Teremos sempre um catálogo de ser- 
viços que deverá ser continuamente revisado, atualizado, integrado, publica- 
do e principalmente usado. 


Aqueles que dizem que finalizaram a etapa de criação do catálogo de ser- 
viços podem até estar se referindo ao fato de terem produzido o artefato que 
dissemos ser tão importante. Se você não tem um catálogo e agora produziu 
um, então terá a sensação de ter concluído uma etapa importante. Mas assim 
como na gestão de configuração, nós podemos criar um CMDB e também 


não podemos dizer que ele um dia está terminado. No exato momento em 
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que você imaginar ter terminado seu levantamento de informações sobre os 
serviços, já terá, infelizmente, deixado para trás muitas mudanças que afeta- 
ram inclusive os serviços que você já levantou. O que mais dizer daqueles que 
neste período foram criados e escaparam de seu levantamento? 

Lembre-se de que o catálogo de serviços a que estamos nos referindo é 
muito maior do que um simples diretório de serviços que será usado para 
ser inserido na sua ferramenta de gestão de atendimento. Como dissemos, a 
criação do nosso catálogo pode ter diversas entradas, inclusive este diretório 
que talvez tenha sido o resultado de sua primeira atividade neste processo. 
Ele não deixa de ser uma importante entrada para o processo de elaboração 
do catálogo de serviços, mas não pode ser visto como a única. A coleta e 
atualização de informações sobre a efetiva utilização dos serviços pelas áreas 
de negócio (o catálogo de serviços de negócio) é um desafio constante à exis- 
tência de um catálogo fidedigno. O mesmo se aplica à coleta e atualização de 
informações técnicas sobre os serviços, principalmente se você não tiver um 


CMDB corretamente estruturado e atualizado. 


LIÇÕES APRENDIDAS: Como todos os demais artefatos produzidos na GSTI, o 
catálogo de serviços requer constantes melhorias. Lembre-se de que o processo 
de gestão de catálogos de serviço não cobre somente a atividade criação do 
catálogo. Após criá-lo, você terá que mantê-lo indefinidamente. Se a empresa e o 
ambiente onde está inserida estão em constante mutação, seu catálogo precisa 
acompanhar estas mudanças. 


QUAIS SÃO AS PRINCIPAIS FALHAS AO SE 
CRIAR UM CATÁLOGO? 


A sequência de assuntos tratados até aqui, desde o Capítulo 1, mostra o que 
consideramos ser o caminho mais adequado para se produzir um catálogo de 


serviços. Porém, além de definir estratégias para agir e produzir o catálogo, 
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teremos também que estar preparados para enfrentar as dificuldades típicas 


deste processo. Vamos abordar algumas delas logo a seguir: 


Falta de 
compreensão do 
papel do catálogo 

de serviços 


Falta de visão 
da importância 
da GSTI 
pelos clientes 


Falta de 
compreensão do 
que é um serviço 


Falta de um 
CMDB íntegro e 
atualizado 


Falta de visão 
da importância 
da GSTI pela TI 


Falta de visão da importância da GSTI pelos clientes 


Muitas vezes, os projetos de GSTI começam pela criação do catálogo de 
serviços, pois as pessoas imaginam que, se irão gerenciar serviços, precisam 
então imediatamente do catálogo de serviços. Partem então para um levan- 
tamento de serviços junto às áreas de negócio, certos de que isso os levará 
ao resultado esperado. O que poderia então parecer uma iniciativa adequada 
pode se mostrar um fator de criação de conflitos. 

Imagine que você esteja numa empresa na qual a TI já vem sendo mal 
vista pelas áreas de negócio, pois não tem atendido adequadamente às de- 
mandas que recebe nem cumprido com os prazos, além de estar executando 
projetos que não produziram os resultados esperados. Ou seja, está desa- 
creditada. Esta mesma área de TI resolve, então, promover um levanta- 
mento dos serviços utilizados pelas áreas de negócio sem que elas tenham 
sido apresentadas formalmente ao projeto de implantação de GSTI. O 
que você, como cliente, pensaria? Sinceramente, eu como cliente pensaria 
que realmente a área de TI está perdida. Se estão vindo até a minha área 
para perguntar que serviços de TI eu utilizo, quando utilizo, de que ma- 
neira eu gostaria de usar, é porque realmente não sabem nada sobre o que 
produzem. Afinal, não foram eles que implantaram todos os serviços e nos 
entregaram para serem usados? Como agora não sabem mais o que eu uso? 
Poderia até pensar que não adiantaria mesmo me preocupar muito com o 
repasse de toda esta informação, pois eles continuariam a trabalhar mal do 
mesmo modo que vêm trabalhando. E então, de que adiantaria saberem o 
que eu uso ou não? 
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Por outro lado, se as áreas de negócio souberem previamente que um 
novo modelo de atuação da TI está sendo implantado e que este novo mo- 
delo será baseado em novos paradigmas, novos modos de atuação, que estará 
focado em produzir resultados para as áreas de negócio, e que, portanto, a TI 
está buscando identificar onde deve se focar para gerar melhores resultados 
de maneira mais rápida, talvez tenhamos uma boa chance de obter apoio a 
nossas iniciativas. 

Pode-se perceber que o problema com as estratégias definidas não está em 
“o que fazer”, mas em “como fazer” e “por que fazer”. A velha questão de que 


tudo deve ser orientado para os resultados também vale aqui. 


Falta de visão da importância da GSTI pela TI 


Criar um catálogo de serviços, como já vimos, pode envolver a execu- 
ção de muitos levantamentos, tabulações e armazenamento de informações 
de mapeamento e controle. Será que sua equipe de TI está preparada para 
assumir estas atividades adicionais se já está, inclusive, sobrecarregada com 
suas atividades operacionais atuais? Muito provavelmente, não. E o que isso 
irá então produzir? Resistência, descrença, falta de estímulo etc. É como se 
tivéssemos contratado um recenseador para trabalhar para o IBGE, mas ele 
já estivesse cheio de outras coisas para fazer e, principalmente, não acredi- 
tasse “neste negócio de estatísticas”. Imagine se ele teria empenho em obter 
os melhores dados? 

Se todos os envolvidos na criação do catálogo, inclusive no nível gerencial, 
não tiverem a correta dimensão da importância deste artefato, será muito 
difícil produzirmos um catálogo realmente bom. Ele poderá até ser um óti- 
mo diretório de serviços, mas nunca um bom catálogo de serviços, pois a 
complementação e manutenção de informações sobre os serviços poderão 
tomar mais tempo do que o imaginado. Isso poderá fazer com que as pessoas 
acabem por acreditar que aquilo que já foi levantado até o momento seja su- 
ficiente e interrompam o processo contínuo de aperfeiçoamento do catálogo. 


Para evitar que isso aconteça é preciso demonstrar o papel desempenhado 
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pelo catálogo de serviços em todos os demais processos operacionais: na ges- 
tão de incidentes, na gestão de nível de serviço, na gestão de mudanças e tan- 
tos outros processos. É normal que a equipe de TI tenha pressa em iniciar as 
atividades da gestão de incidentes (como já vimos), mas será que realmente 
faremos uma boa gestão de incidentes se nem os serviços aos quais estaremos 


atendendo nós conhecermos? 


Falta de um CMDB íntegro e atualizado 


Se o catálogo de serviços é essencial para a gestão de incidentes, tam- 
bém o CMDB é essencial para a gestão do catálogo de serviços. Um dos 
motivos pelos quais sugerimos que o CMDB seja o primeiro artefato a ser 
produzido é justamente para servir de base para acelerar a elaboração do 
catálogo de serviços. O CMDB pode ser produzido sem necessariamente 
envolver o cliente da TI. Pode ser elaborado com um esforço interno da 
TI, pela coleta de informações sobre os itens de configuração que possui. 
Assim, quando iniciarmos o trabalho de elaboração do catálogo de serviços 
e tivermos que envolver o cliente, já teremos uma referência importante 
para basear nosso trabalho e isso poderá transmitir maior confiança aos 
clientes, pois eles verão que conhecemos a estrutura sob as quais os serviços 
estão implementados. 

Se iniciarmos de modo muito prematuro as atividades de levantamento 
do catálogo de serviços sem possuir um CMDB minimamente íntegro e 
atualizado, correremos o risco de expor informações equivocadas ou de 
depender de informações faltantes, o que vai nos expor perante os clientes. 
Novamente, se o objetivo for somente criar um diretório de serviços, talvez 
a ausência de um CMDB realmente não venha a interferir negativamente 
de modo muito significativo em nosso produto final, principalmente se 
reduzirmos o nível de interação com os clientes da TI. Porém, lembre-se: 
o diretório de serviços não é o artefato que desejamos obter no final deste 


processo. 
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Falta de compreensão do que realmente é um serviço 


Já dissemos que a preparação da equipe de TI e dos clientes da TI para 
absorverem os novos conceitos da GSTI é essencial para o sucesso de nosso 
projeto. Especialmente quando o tema for catálogo de serviços, deveremos 
ter muito cuidado em assegurar que todos compreenderam exatamente o que 
significa um serviço, como ele será mapeado no catálogo e como o catálogo 
será útil nos demais processos. Se os clientes continuarem a pensar que um 
serviço é algo parecido com uma tarefa executada pela TI, eles então se per- 
guntarão: por que a TI precisa que eu participe de uma atividade de levan- 
tamento sobre serviços se são eles próprios que executam (sic) estes serviços? 
Se um serviço fosse uma tarefa, então realmente não haveria por que a TI 
perguntar aos clientes sobre as tarefas que ela mesma executa. Mas sabemos 
que um serviço não é uma tarefa e que, para identificar quais serviços o clien- 
te requer para a operação de negócios, realmente temos necessidade de uma 


consulta aos clientes. 


Falta de compreensão do papel do catálogo de serviços 


Por mais completo que um catálogo possa ser, o maior problema que 
pode ocorrer é ele deixar de ser usado diariamente como base para execu- 
ção dos demais processos. Como vimos anteriormente, o catálogo pode ter 
diversos modos de apresentação. O mais perigoso de todos eles é aquele 
que apresenta o catálogo de serviços como um documento textual impres- 
so, ou seja, com uma cara de catálogo de produtos e como algo estático. 
Naturalmente, já durante sua própria elaboração, ele corre o risco de ficar 
desatualizado. Imagine então se você decidir hoje imprimir cópias do ca- 
tálogo de serviços e distribuir a diversas pessoas dentro da empresa. Por 
quanto tempo ele terá informações verdadeiras? Provavelmente somente 
até a primeira alteração de um dos serviços nele contidos e isso pode ser no 


dia seguinte à distribuição. 
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O catálogo de serviços é um ser vivo. Não pode ser transformado em um 
documento que será “guardado dentro da gaveta”. Aqueles que transformam 
o catálogo de serviços em um documento estático não compreenderam o 
papel que ele desempenhará: ele deve ser o mapa fiel dos serviços existentes 
na nossa organização, e não somente uma fotografia de como um dia eles já 
foram. Logo, tanto o conteúdo como o formato de publicação podem ajudar 
a todos os envolvidos no “consumo” de suas informações a perceberem seu 


papel nos processos da GSTI. 


LIÇÕES APRENDIDAS: Não basta criar algo e denominar de catálogo de serviços. 
É essencial que ele esteja em conformidade com os conceitos da ITIL® e que 
seu cliente perceba o que ele significa para o sucesso do negócio. Tome cuidado 
para não mapear o que a TI sabe fazer (tarefas), mas sim para mapear o que a TI 
entrega a seus clientes (serviços). 


HAVERIA UM MODELO A SER SEGUIDO? 


É difícil falar em um modelo ou um padrão a ser adotado. Os próprios 
livros oficiais da ITILº não apresentam claramente nenhum exemplo de um 
catálogo de uma empresa real ou mesmo fictícia. Isso, com certeza, porque 
a ITILº procura sempre transmitir a ideia “do que deve ser feito” e não 
de “como deve ser feito”, e com o catálogo não seria diferente. Mostrar 
um modelo de um catálogo seria exemplificar “como ele é” e não “o que ele 
contém”. 

Ao analisar inúmeros exemplos de catálogos de serviços citados em fó- 
runs, publicações e até cursos, temos que ter muito cuidado em validar se 
a lista de serviços apresentados realmente contém serviços ou se contém 
tarefas. Recentemente vi um artigo publicado na internet sobre catálogos 
de serviços em que vários sites de universidades americanas eram cita- 


dos como exemplo. Ao acessar vários deles, encontrei serviços tais como 
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“instalar equipamento”, ou “esclarecer dúvidas”. O que podemos concluir? 
Estes não eram realmente catálogos de serviços da ITILº, mas catálogos 
de serviços de marketing, em que a TI apresenta aquilo que é capaz de fazer 
para “vender sua mão de obra” ou deixar seus “serviços à disposição para 
serem requisitados”. 

Em um projeto no qual participamos em uma empresa de serviços tive- 
mos, na fase inicial, este tipo de “ruído de comunicação”. Por se tratar de 
uma empresa de consultoria que “executava vários serviços” para seus clien- 
tes, a cada vez que falávamos em catálogo de serviços (da ITILº) as pessoas 
envolvidas imaginavam o catálogo de serviços que apareceria em seu folder 
institucional com as atividades que eles desenvolviam para seus clientes, ou 
seja, uma visão de marketing. Tivemos que gradualmente mostrar que real- 
mente existiam dois catálogos de serviço: um com serviços oferecidos pela 
TI na visão ITILº e outro com serviços executados pela empresa na visão 
do marketing. Como atualmente muitas empresas oferecem seus produtos 
numa modalidade as a service, cada vez mais estes dois catálogos (TTILº e 
marketing) estão se aproximando e criando uma fronteira muitas vezes difícil 


de ser claramente definida. 


TABELA 2 
Gestão de Gestão de Gestão 
Termo Marketing serviços projetos corporativa 
Serviço X X X 
Configuração X X 
Mudanças X X X 


Várias terminologias que a ITIL® utiliza são semelhantes a outras usadas 
em diversos ambientes e geram confusão se não forem bem esclarecidos. 
Já vimos também ocorrerem mal-entendidos com várias pessoas que falam 


de gestão de configuração e acham que o conceito da ITILº é o mesmo 
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conceito do processo de desenvolvimento de softwares. A gestão de mudan- 
ças da ITIL® é também muitas vezes confundida com a gestão de mudanças 
no escopo empresarial e também com a gestão de mudanças do processo de 
desenvolvimento de software. Procure sempre estabelecer uma linguagem 
comum entre os participantes do projeto de GSTI, sejam eles internos ou 
externos. Pergunte-se sempre: será que o que eu estou falando está realmente 
sendo entendido como deveria? 


LIÇÕES APRENDIDAS: No catálogo de serviços e em outros artefatos da ITIL®, o 
conteúdo deve ser mais importante do que o formato. Se o conteúdo for apropria- 
do, você poderá até encontrar formatos diferentes para transmitir este conteúdo. 
Quando buscar um modelo de referência, avalie primeiro o conteúdo e só depois 
o formato. 
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Preparar a empresa para a GSTI 
Preparar a TI para a GSTI 
Construir um CMDB 
Construir um Catálogo de Serviços 


Construir Acordos de Nível de Serviço 


Construir uma Base de Conhecimento 


Implantar processos operacionais 


S eguindo nossa linha de raciocínio, temos que primeiramente estruturar 
um CMDB. Logo em seguida devemos produzir um catálogo de serviço 
usando informações do CMDB para acelerar este processo e dar confiabili- 
dade às informações que vamos levantar junto aos clientes. A terceira fase a 
ser abordada será a criação dos acordos de nível de serviço para cada um dos 
itens do catálogo de serviço, isto, é claro, considerando que estamos atuando 
sobre os serviços que já estão em operação. Se estivéssemos desenhando novos 
serviços, com certeza esta atividade viria já na fase de desenho do serviço. 

Se já tivermos um catálogo de serviços bem elaborado e um CMDB que 
nos dê informações seguras sobre os recursos de que podemos dispor para 
oferecer em níveis de serviços, conforme as demandas das áreas de negócio, 


poderemos então realmente negociar o atendimento das demandas de modo 


consciente e responsável. 


CATÁLOGO 
DE EEE) 
SERVIÇOS ANS 


Veremos nos tópicos a seguir que o estabelecimento de níveis de serviço 
factíveis é uma tarefa difícil, pois sabemos que a demanda sempre supera os 
recursos de que dispomos. Se não tivermos informações confiáveis e reais so- 
bre os itens de configuração e ativos de serviços, então o processo de negocia- 


ção poderá deixar de ser um critério técnico-operacional para se transformar 


ITIL - GUIA DE IMPLANTAÇÃO 


num critério político-hierárquico no qual aqueles que têm maior influência 
acabam por receber mais recursos. 

Muitos projetos que buscam a implantação da GSTI baseada na ITILº 
têm como objetivo conseguir atender melhor aos clientes. A maior parte 
deles tem um ponto em comum: melhorar os prazos de atendimento das 
demandas. 

A reclamação mais frequente é que a TI não atende as áreas de negócio 
dentro dos prazos esperados. Pensando em corrigir esta falha, muitos gesto- 
res e até o próprio pessoal do nível operacional acredita que com as melhores 
práticas da ITILº aplicadas aos processos, como as de gestão de incidentes 
e cumprimento de requisições, obterão melhores resultados no atendimento 
das principais demandas que recebe. Acham que, com isso, os clientes da TI 
passarão a perceber um melhor desempenho da área. Infelizmente, esta não 
é uma verdade completa. 

Usando uma analogia, poderíamos comparar esta ideia de que mudar os 
processos isoladamente irá produzir maior satisfação aos clientes ao caso de 
um motorista de táxi que, querendo atender melhor a seus clientes, passa a 
dirigir de modo mais arrojado e veloz pelas ruas da cidade para chegar antes 
aos destinos. Porém, esqueceu-se de pesquisar junto aos clientes se eles real- 
mente têm pressa ou se estão a passeio e gostariam de poder observar melhor 
a paisagem, ou se gostariam de maior conforto em vez de rapidez, ou até se 
gostariam de um trajeto mais curto e barato em vez de um mais longo per- 
corrido no mesmo tempo, e por aí afora. 

Será que nossos clientes ficarão plenamente satisfeitos com a TI se so- 
mente reduzirmos o tempo de atendimento de suas demandas? Será que eles 
querem ter seus problemas resolvidos de modo mais rápido? Ou será que 
prefeririam esperar mais por soluções definitivas que não voltassem a apre- 
sentar novas falhas em curto espaço de tempo? Talvez estejamos pensando 
em melhorar nosso processo de gestão de incidentes quando na verdade de- 
veríamos estar pensando em implantar o processo de gestão de problemas. 

Fazer mais e mais rápido nem sempre é sinônimo de qualidade percebida 
pelo cliente. Em alguns casos, talvez eles desejem outras formas de valoração 


de qualidade de serviço, tais como: esmero, capricho, atenção, dedicação, 
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eficácia etc. Não seria o caso de, assim como o motorista de táxi, pergun- 
tarmos primeiro a nossos clientes o que eles desejam antes de mudar nosso 


modus-operandi? 


LIÇÕES APRENDIDAS: Seus clientes não querem melhores processos. Eles que- 
rem melhores resultados. Conheça suas expectativas antes de querer atendê-las. 
Talvez o seu conceito de melhoria que a TI imagina implantar não seja o mesmo 
que o cliente espera receber. 


TODOS CONHECEM O QUE É UM ANS? 


Desde o início deste livro, temos insistido que um dos principais respon- 
sáveis pelo sucesso da implantação da GSTI é o próprio cliente da TI. Se o 
cliente não absorver alguns novos conceitos e paradigmas deste novo modo 
de operação da TI, então muitas das iniciativas de adoção de melhores prá- 
ticas poderão se transformar em “pesadelos”, tornando a convivência ainda 
pior entre as partes. 

Para negociar um acordo de nível de serviço (ANS), o cliente precisará 
ter muito claro qual é o conceito de serviço. Precisará também compreen- 
der os princípios da ITILº que direcionam todos os esforços da TI para 
que se assegure de que os serviços serão entregues e mantidos operacionais, 
atendendo aos requisitos de negócio. Já no Capítulo 1 abordamos uma sé- 
rie de novos comportamentos que precisarão ser esperados (e cobrados) dos 
clientes da TI. Muitos dos comportamentos errôneos existentes precisam ser 
readequados a uma nova realidade focada em produção de resultados para as 
áreas de negócio, e não para resultados pessoais. 

Um novo conceito que o cliente deve absorver corretamente é o de ANS 
(Acordo de Nível de Serviço) ou SLA (Service Level Agreement). “Absor- 
ver” significa aqui “absorver corretamente”, pois parece que muitos clientes 


já absorveram este conceito, mas o absorveram de modo errado. 
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Escopo do atendimento 


Responsabilidades das partes 


OONO AE Mil Disponibilidade do serviço 


de Serviço 


Regras de utilização do serviço 


Entre outras... 


Muita gente hoje fala em SLA como se fosse somente um compromisso 
com um prazo de atendimento de uma demanda. Para muitos, SLA é si- 
nônimo de prazo de atendimento! Existem projetos nos quais, ao final da 
atividade de definição dos SLA, o que é produzido é uma lista de tarefas que 
a TI deve executar acompanhada dos tempos em que cada uma deve ser exe- 
cutada. E, ainda pior, é que todos acham que acabaram a definição do SLA 
quando chegaram a este resultado. Cuidado! SLA é muito mais que isso. Se 
uma lista de tarefas que a TI tem a executar não é um catálogo de serviços, 
então colocar um prazo para execução destas tarefas também não irá gerar 
um SLA. 

Aqueles que pensam que um SLA é só um compromisso de prazo para 
execução de uma atividade muitas vezes foram induzidos a pensar dessa for- 
ma, pois o que deveria ser um catálogo de serviços é na verdade um catálogo 
de tarefas que a TI executa. Aí, se para cada tarefa criarmos um prazo de 
execução todos pensarão que o SLA é só isso. Se nosso catálogo de serviços 


for realmente uma lista de serviços, e não uma lista de tarefas, este risco pode 
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ser minimizado. Fica evidente que criar um bom catálogo de serviços é o 
primeiro passo para criar um bom SLA. 


Criação 
do catálogo 
de serviços 


Criação 
do CMDB 


Definição 
dos ANS 


Um acordo de nível de serviço como nos apresenta a ITILº é um artefato 
que nos provê uma série de informações sobre compromissos, responsabili- 
dades, obrigações e direitos entre as partes envolvidas na entrega e no rece- 
bimento dos serviços de TI. Perceba que estamos falando de compromissos, 
responsabilidades e direitos mútuos, ou seja, para ambas as partes. Não es- 
tamos falando somente de criar prazos para que a TI atenda a chamados 
das áreas de negócio. Será que seu cliente sabe que a partir de um ANS ele 
também terá compromissos e obrigações a cumprir para poder receber os 
benefícios que a outra parte (a TT) tem a oferecer? 

Se olharmos para a teoria da TTILº, o SLA de um serviço nasce já na fase 
de design do próprio serviço. Isso nos mostra que o conceito de serviço, de 
catálogo de serviços e de acordo de nível de serviço deve ser transmitido o 
mais cedo possível para nossos clientes. Devemos informá-los de que itens 
tais como horário de uso, quantidade de usuários, disponibilidade, capacida- 
de, tempo de resposta a transações, tempo de reparo, abrangência, segurança 
de acesso, infraestrutura fornecida, know-how a ser absorvido, entre muitos 
outros tópicos, deverão compor a definição do nível de serviço esperado para 
um determinado serviço que está sendo desenhado. 


LIÇÕES APRENDIDAS: Não deixe que o ANS se transforme num mero compromis- 
so de tempo de atendimento a chamados. Procure meios para esclarecer o que 
é e o que não é um ANS. Demonstre sua real finalidade a todos os envolvidos na 
sua definição, criação, manutenção e uso. 
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QUEM SERÁ O BENEFICIADO COM O ANS? 


Se muitos já pensam que o tempo gasto com a elaboração de um CMDB 
e de um catálogo de serviços pode ser um “atraso” num projeto de GSTI, o 
que dizer do tempo a ser gasto com a coleta e documentação de informações 
sobre os níveis de serviços desejados? Mas não é só isso. O que dizer então 
das tarefas de acompanhamento dos níveis de serviço que serão efetivamente 
entregues? Se documentar informações sobre os níveis desejados já é traba- 
lhoso, o que dizer da coleta e documentação de informações sobre os níveis 
praticados? 

O senso comum nos faz pensar que o estabelecimento de um SLA é um 
mecanismo de proteção dos interesses do cliente. Podemos pensar que é um 
artefato voltado para ele. Porém, certa vez, uma ideia me intrigou: Quem na 
TI estaria interessado em investir tanto tempo em atividades de definição 
de parâmetros para qualidade do serviço se, na prática, depois tudo irá se 
resumir a fazer o que é possível? Se já estamos limitados a fazer o possível (e 
às vezes até o impossível), para que então definir tantas outras coisas? Não 
seria mais prático nos comprometermos a fazer sempre o melhor para todos? 
Quem ofereceria menos do que pode dar? 

Foi pensando nestas perguntas que descobrimos que o SLA pode ser uma 
ferramenta tão importante para a TI quanto para o próprio cliente. É claro 
que isso só será verdade se tivermos um SLA que realmente expresse com- 


promissos e direitos para ambas as partes e não somente que seja unilateral. 


DE TI de Serviço 


CLIENTE 2 


CLIENTE 1 
PROVEDOR DE 
SERVIÇOS Acordo de Nível 


Os benefícios que o cliente poderá obter são claramente identificá- 
veis quando se observam os requisitos do serviço que foram especificados. 


Há, porém, um primeiro aspecto importante a ser destacado neste tópico: 
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estamos falando de benefícios para o cliente e não para os usuários. De- 
vemos falar sempre em benefícios para uma área de negócio quanto ao 
cumprimento dos seus objetivos, mas isso não necessariamente quer dizer 
que nosso SLA vai se traduzir em benefícios pessoais para os usuários deste 
serviço naquela área de negócio. Porém, acreditamos que este ponto já es- 
teja claro desde o Capítulo 1 quando pudemos definir que nosso plano de 
melhoria de qualidade da GSTI é focado em resultados organizacionais e 
não em resultados pessoais. 

O benefício que a TI poderá obter com a criação de um SLA formal é, em 
primeiro lugar, o estabelecimento das condições de fornecimento do serviço, 
em termos de horários, quantidades, tempos de resposta etc. 

Se por um lado isso pode parecer o estabelecimento de objetivos a serem 
atingidos, por outro, pode também ser visto como um limitante para o for- 
necimento. Por exemplo, se o SLA criado estabelecer que para o serviço de 
correio eletrônico, a ser fornecido para o cliente Departamento de Recursos 
Humanos, devem ser criadas 50 contas, cada uma com capacidade para três 
mil mensagens por mês, teremos então um elemento formal para limitarmos 


o uso de recursos além desta capacidade estabelecida. 


Área B 


Isso não quer dizer que não possamos oferecer mais do que o limite que 


foi acordado. Até podemos, mas deixamos de ter o compromisso em atender 
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a qualquer demanda extra não planejada. Passamos a ter a possibilidade, 
dentro de nosso critério de extensão de capacidade planejada, de atender a 
crescimentos não previstos de demanda. Porém, se isso não for possível, a 
TH fica isenta de assumir a culpa pelo não atendimento das demandas deste 
departamento. O que poderia ser visto como um compromisso pela TI passa 
a ser um limitante de responsabilidade. 

Este mesmo raciocínio serve para o caso de uma solicitação adicional de 
serviços que esteja fora do SLA, para atendimento em regimes emergenciais 
também não previstos, para priorização de atendimentos fora das regras pre- 
definidas etc. Tudo passa a ter uma possibilidade de atendimento pela TI, 
desde que esta julgue apropriado. Porém, se a decisão for por não atender 
à demanda extra, deixa de haver uma quebra de expectativas com o cliente. 
Ele estará ciente de que a obrigação assumida pela TI é estritamente aquela 
citada no SLA. 

Outro benefício que a TI pode obter com a formalização de SLA com 
diferentes áreas de negócio da organização é o fato de haver explicitamente a 
documentação das demandas de cada área. 

É muito difícil a TI justificar sem este elemento que não tem mais recursos 
para atender uma área X porque a área Y já requereu os recursos previamente 
para ela. Com o SLA formalmente estabelecido, cada área poderá ver quem 
são os tomadores de recursos que estão “monopolizando” a atenção da TI e 
causando restrições ao atendimento das demandas de sua área. É como se a 
TI dissesse: “Nós até gostaríamos de atender a todas as suas demandas, mas 
olhe aqui neste documento: já estamos fornecendo o recurso que você pediu 
para outra área. Se você também precisa deste recurso, então negocie direta- 
mente com a outra área para verificar se ela pode lhe liberar parte dele...” 

Veremos um pouco mais sobre este tema quando falarmos do processo de 
criação dos SLA. 

Ainda outro benefício para a TI com a formalização dos SLA é a criação 
de uma memória evolutiva do perfil de consumo de serviços pelo cliente. 
Tanto o crescimento como a redução do uso de serviços pelas áreas de negó- 


cio é uma constante nos meios corporativos. À TI, às vezes, se vê compelida 
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a absorver as mudanças de perfil de uso dos serviços “informalmente”. Se 
não houver um SLA estabelecido, os picos de uso de recursos ou até os usos 
eventuais de um serviço podem ficar esquecidos com o passar do tempo. Será 
difícil justificar entre as áreas por que uma delas foi degradada ou não foi 
atendida se não tivermos uma visão transparente de que outra área naquele 
mesmo período estava comprometendo a capacidade de fornecimento da TI, 


mesmo que momentaneamente. 


Consumo mensal de espaço em disco 


Jan Fev Mar Abr Mai 


Por último, temos ainda mais um benefício para a TI: o estabelecimento 
de compromissos para o cliente pela TI. Como já citamos, o SLA é um acor- 
do com compromissos bilaterais. Isso significa que, ao assiná-lo, o cliente 
está se comprometendo também a cumprir regras e condições estabelecidas 
no SLA. Se o cliente não cumprir a parte dele no acordo, a TI poderá tam- 
bém alegar que não conseguiu cumprir a sua parte por falta de condições que 
deveriam ser propiciadas pelo próprio cliente. 

Vamos imaginar um cenário em que um serviço de impressão deva apre- 
sentar uma disponibilidade de 90% em horário comercial, ou seja, podendo 
ser interrompido até quatro horas por semana, sendo aceitas até quatro para- 
das de no máximo uma hora cada. Este passa a ser então o compromisso de 


disponibilidade do serviço de impressão assumido pela TI. 
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TABELA 1 
Qtde. de horas | Qtde. de Disponibilidade Qtde. de Tempo de 
comerciais na | horas de eventos parada em 
semana interrupção cada evento 
40 4 90% ou 36 horas 4 1 hora 


Porém, a TI, como cláusula complementar, fez figurar no SLA que este 
compromisso será cumprido desde que o cliente não altere as configurações 
da impressora sem prévia autorização da TI. Ou seja, se as configurações 
feitas pela TI forem mantidas sem alteração ela se responsabiliza pelo correto 
funcionamento. 

Se o cliente mexer nas configurações e causar alguma falha que esteja fora 
do controle da TI, o prazo de restauração do serviço já não pode mais ser 
assegurado dentro de no máximo uma hora. Talvez a TI tenha que gastar 
duas ou três horas para estudar a nova falha gerada e, nesse caso, mesmo o 
atendimento sendo feito fora do tempo preestabelecido, não haverá descum- 
primento ao SLA, pois os pré-requisitos que deveriam ter sido respeitados 
pelo cliente não o foram. 

Essa situação demonstra que a TI não ficará mais “refém” de um com- 
promisso assumido a despeito de quaisquer condições que se apresentem. 
Os compromissos serão, sim, cumpridos, desde que a outra parte também 
os cumpra. Não iremos utilizar este princípio para “justificar” atrasos e o não 
cumprimento de obrigações, mas para “motivar” o cliente a cumprir os com- 
promissos estabelecidos para ele. Se formos hábeis no estabelecimento dos 
acordos, poderemos ter uma excelente ferramenta para evitar que os clientes 
mudem configurações, instalem softwares não autorizados, mexam em equi- 
pamentos, usem recursos além das medidas estabelecidas etc., em resumo: 
para que sigam as regras. 

Se os clientes desejam melhores níveis de serviços e existe um SLA, en- 
tão os próprios clientes passam a ser responsáveis pelos resultados a serem 


apresentados pela TI. Deixamos de ter somente um cliente demandando 


178 


COMO IMPLANTAR E MANTER UM ACORDO DE NÍVEL DE SERVIÇOS? 


qualidade para termos um cliente que também é corresponsável pela manu- 
tenção da qualidade. 

Há um ditado popular que diz: “O combinado não custa caro.” Podería- 
mos complementar dizendo: “Mas é preciso registrar o que foi combinado, 
senão nunca saberemos se estamos pagando a mais ou recebendo de menos.” 


Esta é, em resumo, a função do SLA para a TI. 


LIÇÕES APRENDIDAS: Um ANS deve trazer benefícios e responsabilidades para 
ambas as partes do acordo. Se não for assim, ele deixa de ser um acordo e se 
transforma em um contrato no qual alguém estabelece regras e o outro segue. Em 
um acordo deve haver equilíbrio de obrigações e benefícios. Deve haver também 
um objetivo em comum: atingir o nível de serviço combinado. Para isso, é neces- 


sário que todos cumpram a sua parte. 


QUAL A DIFERENÇA ENTRE ANS E PRAZO DE ATENDIMENTO? 


Como já dissemos, é muito frequente que o tema SLA acabe sendo trata- 
do de modo simplificado, como se representasse somente uma preocupação 
com o estabelecimento de um prazo para atendimento de solicitações. É 
muito comum ouvirmos referências como “nosso SLA é de duas horas” ou 
“estamos dentro do SLA”, querendo representar que o prazo não foi ainda 
ultrapassado, e assim por diante. 

Se somente este aspecto do SLA se espalhar pela organização durante 
a fase de implantação da GSTI estaremos criando uma armadilha para os 
próprios clientes e também para a TI. A medição de tempos de atendimento 
pode em certas situações prejudicar os clientes e, em outras, prejudicar a TI. 
Vejamos como pode acontecer. 

Se você retornar aos conceitos que viu no treinamento de ITIL Founda- 


tionsº sobre SLA, verá que tudo começa com uma definição de requisitos de 


179 


ITIL - GUIA DE IMPLANTAÇÃO 


nível de serviço (SLR). Esta definição irá abordar diversos aspectos os quais 
não iremos revisar aqui. Porém, um deles é essencial ao nosso raciocínio: a 
disponibilidade do serviço. Como você já sabe, é importante que os clientes 
definam qual é a disponibilidade esperada para o serviço que será provido 


pela TI. Vamos ver então dois cenários possíveis: 


CENÁRIO 1 


Um cliente define que precisa de um serviço operando 24 horas por dia, 7 
dias por semana, e que requer 99% de disponibilidade deste serviço, aceitan- 
do interrupções máximas do serviço de 2 horas. 


Tempo total do serviço: 7 dias x 24 horas x 4 semanas = 672 horas 
no mês 


Indisponibilidade aceitável no mês = 1% = 6h43 

Chamados atendidos no mês: 10 

Tempo de resolução de cada chamado: 1h 

Tempo total de parada no mês: 10h 

Quantidade de chamados atendidos com mais de 2 horas: O 


RESULTADO APARENTE: SLA atendido, pois nenhum chamado gastou mais 
de 2 horas para ser atendido. 


RESULTADO REAL: SLA não atendido apesar de o tempo de atendimento 
de 2 horas nunca ter sido ultrapassado para nenhum dos 10 chamados 
atendidos. 


PREJUDICADO SE O CRITÉRIO “TEMPO DE RESOLUÇÃO” FOSSE O ÚNICO 
OBSERVADO: O cliente. 
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MOTIVO: A TI teria o indicador de que nenhum chamado ultrapassou o tem- 
po de 2 horas para ser atendido, porém a disponibilidade total do serviço 
teria sido de somente 98,5%, ou seja, 662h/672h (logo, abaixo dos 99% 
exigidos). 


Isso demonstra que avaliar somente o tempo de resolução gasto em cada 
chamado contra um tempo máximo estabelecido não é suficiente. 


CENÁRIO 2 


Um cliente define que precisa de um serviço operando 8 horas por dia, 5 
dias por semana (de segunda a sexta), e que requer 99% de disponibilidade 
deste serviço, aceitando interrupções máximas do serviço de 30 minutos. 


Tempo total do serviço: 5 dias x 8 horas x 4 semanas = 160 horas no 

mês 

Indisponibilidade aceitável no mês = 1% = 1h36 

Chamados atendidos no mês: 3 
Chamado 1: segunda-feira — tempo de parada de 20 minutos 
Chamado 2: sexta-feira — tempo de parada de 10 minutos 
Chamado 3: sábado — tempo de parada de 1h30 

Tempo total de parada no mês: 2h 


Quantidade de chamados atendidos com mais de 30 minutos: 1 


RESULTADO APARENTE: SLA não atendido, pois um dos chamados supe- 
rou o prazo de 30 minutos de resolução estabelecido. 


RESULTADO REAL: SLA atendido apesar do tempo de atendimento de 30 
minutos ter sido ultrapassado em um chamado. 
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PREJUDICADO SE O CRITÉRIO “TEMPO DE RESOLUÇÃO” FOSSE O ÚNICO 
OBSERVADO: A TI. 


MOTIVO: A TI teria o indicador de que um chamado ultrapassou o tempo 
de 30 minutos, porém a disponibilidade total do serviço foi de 99,68%, 
considerando-se somente a disponibilidade oferecida em horário comer- 
cial, ou seja, 159,5h/160h. 


Mais uma vez, está demonstrado que somente comparar um prazo de 
atendimento de chamados com a duração de cada um é insuficiente. 

A raiz de grande parte dos problemas de má interpretação dos SLA é que 
poucas empresas estão preparadas para efetivamente medir a disponibilidade 
de um serviço. À maioria consegue medir tempos de resolução de incidentes, 
mas não os associa efetivamente a um serviço e, portanto, não consegue de- 
pois tabular a disponibilidade dos serviços. O que é tabulado, na maior parte 
das vezes, é meramente o tempo de atendimento de um chamado, por isso a 
simplificação de comparar somente o tempo de resolução com um tempo de 
atendimento previsto é a única alternativa que resta. 

Se as empresas continuarem a registrar seus chamados de incidentes indi- 
cando somente, por exemplo, que o item afetado foi o “browser”, sem apon- 
tar que, naquele momento, para o usuário, o serviço afetado era o de “reserva 
de passagens”, como então iremos medir no final do mês quantas horas de 
disponibilidade do serviço de “reserva de passagens” nós conseguimos ofere- 
cer para aquele cliente? 

Podemos até saber quantas horas o “browser” esteve disponível na má- 
quina daquele usuário, mas identificar quais serviços foram afetados quando, 
naquele dia, ele estava indisponível será uma mera prática de adivinhação! 
Esse cenário reforça mais uma vez o fato de que o catálogo de serviços é es- 


sencial, neste caso, para o registro e tratamento de incidentes e SLA. 
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A medição de disponibilidade de um serviço é essencial para se avaliar 
um SLA. Muitos softwares hoje oferecem medições de disponibilidade de 
componentes (ou de itens de configuração). Porém, de que adiantaria termos 
uma medição precisa da disponibilidade de cada um dos componentes da 
rede se não os tivermos corretamente associados no CMDB? Isso também 
reforça o fato de que um CMDB bem organizado é essencial para uma cor- 
reta apuração de disponibilidade de um serviço. Se este recurso também não 
estiver corretamente implantado, teríamos outra deficiência na apuração de 


atendimento de SLA. Veja o cenário a seguir: 


CENÁRIO 3 


Um cliente define que precisa de um serviço operando 8 horas por dia, 
5 dias por semana (de segunda a sexta), e que requer 99% de disponibili- 
dade, aceitando interrupções máximas do serviço de 30 minutos. Porém, o 
cliente não tem um processo de gestão de eventos, somente um processo 
de gestão de incidentes reativo e baseado em queixas dos usuários do 


serviço. 


Tempo total do serviço: 5 dias x 8 horas x 4 semanas = 160 horas no 


mês 
Indisponibilidade aceitável no mês = 1% = 1h36 
Chamados atendidos no mês: O 


Tempo total de parada no mês: 2h (o link deixou de operar temporaria- 
mente e voltou a operar sem intervenção da TI) 


Quantidade de chamados atendidos com mais de 30 minutos: O 


RESULTADO APARENTE: SLA atendido, pois não houver incidentes regis- 
trados que pudessem levar a uma indicação de indisponibilidade. 
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RESULTADO REAL: SLA não atendido apesar de nenhum chamado ter sido 
registrado e superado o tempo de 30 minutos. 


PREJUDICADO SE O CRITÉRIO “TEMPO DE RESOLUÇÃO” FOSSE O ÚNICO 
OBSERVADO: O cliente. 


MOTIVO: A Tl teria o indicador de que nenhum chamado ultrapassou o SLA 
de 30 minutos, porém a disponibilidade total do serviço foi de somente 
98,75% (informação esta apurada junto aos componentes dos serviços, e 
não junto a chamados atendidos). 


Pode-se constatar que realmente a correta avaliação de um SLA en- 
volve muito mais do que somente a medição de tempos de atendimento 
de um chamado. Se isso for feito, podemos induzir a erros de interpreta- 
ção que beneficiarão ou prejudicarão tanto o cliente como a TI, conforme 


o cenário. 


LIÇÕES APRENDIDAS: À ênfase excessiva que os clientes dão ao tempo de aten- 
dimento de um chamado é um sintoma típico de que talvez seu service desk con- 
tinue a operar como um help desk. Este é um vício transmitido pela própria Tl aos 
seus clientes por acreditar que o SLA significa só “tempo de atendimento”. Como 
agravante desta situação, percebemos ainda que a maior parte dos tempos me- 
didos não expressa valores relativos aos serviços, mas sim aos componentes. Ou 


seja, tanto o foco como a medição podem estar errados. 
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COMO CRIAR UM ANS? 


À primeira característica de um ANS que deve ser realçada vem da pri- 
meira palavra que o forma: “acordo”. A maior parte das pessoas que sai dos 
cursos de ITIL Foundationsº sabe que este acordo é necessário. Isso faz 
parte da teoria estudada. Porém, a prática nos mostra que uma das falhas que 
normalmente são cometidas é se concentrar somente nos acordos entre a TI 
e as áreas de negócio (como manda a teoria). Porém, o acordo mais difícil de 
ser conseguido não é entre a TI e as áreas de negócio, mas entre as próprias 
áreas de negócio entre si. Este aspecto não fica muito claro nos livros atuais 
da ITIL® e talvez mereça um novo tópico nas próximas versões. 

O que a teoria nos diz é que, independentemente da modalidade de ANS 
que escolhamos definir, ele será um acordo entre a TI e a área de negócio. 
O que a teoria, entretanto, não deixa claro, mas que a prática é definitiva em 
nos mostrar, é que a negociação com uma área pode ser influenciada pelas 
negociações previamente realizadas com as demais áreas e que esta também 
poderá afetar as próximas negociações. Isto parece óbvio: se a área X exigir 
certo nível de serviço e a área Y já tiver estabelecido previamente condições 
que nos impeçam de atender plenamente os requisitos da área X, teremos 
então um conflito de interesses. 

Estes conflitos de interesse podem ser tão simples como várias áreas exi- 
girem um atendimento prioritário no mesmo momento. Podem também 
envolver questões mais complexas, como várias áreas exigirem capacida- 
de ou disponibilidade de serviços em escalas que a TI não tem condições 
de suprir simultaneamente. E, nessa hora, quem deve resolver a questão? 
Depende. 

Sempre é bom lembrar nos processos de criação de ANS que, se todas as 
áreas se definirem como prioritárias, a prioridade deixará de existir, pois vol- 
taremos a nivelar todo mundo em um novo patamar, porém sem distinções. 
Também é bom lembrar que se temos uma quantidade finita de recursos e 
a somatória das demandas de cada área for maior que o total de recursos de 
que dispomos, alguém terá que abrir mão de sua demanda, reduzindo-a, ou 


então a TI precisará receber mais recursos para poder atender a todos. 
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É neste contexto que podemos propor, então, que a TI utilize uma abor- 
dagem similar àquelas praticadas nas demais áreas, como na área financeira 
e no RH. 

Imagine primeiro que, chegando o final de ano, todos os diretores das 
diversas áreas de negócio da organização se reúnem para definir seus or- 
çamentos para o próximo ano. Cada um apresentará seus projetos, suas 
demandas e sua necessidade de recursos. O que aconteceria, então, se a 
somatória dos recursos financeiros que cada área deseja receber fosse maior 
do que a capacidade do orçamento anual? Onde aconteceriam os cortes? 
Quem definiria onde seriam feitos os cortes? À área financeira? Provavel- 
mente não sozinha. Só porque esta área faz a gestão dos recursos financei- 
ros não significa que ela seja totalmente responsável por definir qual área 
irá receber menos recursos financeiros no próximo ano. Esta é uma decisão 
estratégica da organização. É uma escolha que requer consenso baseado 
num planejamento estratégico e na participação de cada área no cumpri- 
mento das metas definidas. 


TABELA 1 
Area desejado orçamento global | ajustado 
Diretoria 1 100 mil 100 mil 
Diretoria 2 200 mil Paini 150 mil 
Diretoria 3 300 mil 250 mil 
TOTAL 600 mil 500 mil 


O mesmo ocorreria na área de RH se, no mesmo panorama, imaginásse- 
mos que para o próximo ano poderemos dispor somente de 50 novas vagas e 
tivéssemos uma demanda total de vagas, entre todas as áreas da organização, 
que superasse este limite. Quem deveria definir qual seria o setor da empresa 
que reduziria suas vagas e quem ficaria com a maior parte delas? O RH? 


Também não. Novamente, é uma decisão estratégica. 
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O que estas analogias nos ensinam? Que se a TI tem recursos limitados 
(pessoas, servidores, discos, tempo para atendimento, links etc.) e as deman- 
das dos serviços de cada área superam estes limites, também não deveria ser a 
TI a responsável por definir sozinha quem ela irá atender ou não, quem terá 
prioridades num caso de falta de recurso, e por aí afora. A TI é uma prove- 
dora de serviços que devem estar alinhados com as estratégias de produção 
de resultados para as áreas de negócio, portanto, novamente trata-se de uma 
definição estratégica a ser realizada pelo board da empresa ou pelo consenso 
entre as próprias áreas de negócio. Mas nem sempre é isso o que ocorre. 

Existindo, então, uma definição de prioridades, de capacidades a serem 
alocadas, de recursos necessários para cada área, produzidas pela própria ne- 
gociação entre elas e com o apoio, mas não com a decisão, da TI, teremos 
atingido uma gestão de nível de serviço profissionalizada. 

Se todos entenderem que os ANS foram definidos não para atender às 
necessidades da TI, ou por exigência da ITIL®, mas sim para formalizar as 
condições estratégicas definidas pela corporação, condições estas que não 
beneficiam áreas ou pessoas, mas que potencializam as chances de atingir os 
resultados do negócio, talvez tenhamos boas possibilidades de que os demais 
processos recomendados pela TTILº sejam mais bem absorvidos, principal- 
mente aqueles baseados em prioridades. 

Já abordamos no Capítulo 1 o fato de que uma das principais mudanças de 
comportamento que as próprias áreas clientes da TI precisam demonstrar é 
deixar de buscar interesses próprios e ter uma visão corporativa. Se este con- 
ceito não for realmente absorvido e praticado, os ANS poderão até expressar 
as necessidades individuais de cada área, mas não estarão alinhados com as 
necessidades de geração de resultados da organização como um todo. 

Imagine uma empresa que tem como objetivo aumentar suas vendas, mas 
que, por uma negociação isolada de ANS entre a TI e cada uma das outras 
áreas, acaba por dar prioridade à área de produção, o que fez aumentar ainda 
mais seus estoques. Ela deixou de priorizar a área de vendas, que justamente 
daria vazão aos estoques já elevados que possui. Poderemos ter um ANS 
plenamente atendido sem, no entanto, produzir os resultados esperados pela 


organização. 
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Outra questão essencial que precisa ser levada em conta quando se fala 
de criar um ANS é estabelecer níveis de serviços realistas e exequíveis. 
De que adianta estabelecer condições num ANS se elas não podem ser 
cumpridas? 

Existem situações em que tempos de reparo para alguns incidentes ou 
tempos de atuação em alguns tipos de solicitações de serviço são estabeleci- 
dos sem qualquer base prática. Vamos usar novamente uma analogia. 

Imagine que você tenha que assumir um compromisso de entrega de en- 
comendas em destinos diversos. Você estabelece, então, que poderá entre- 
gar qualquer encomenda solicitada em até quatro horas. Este é seu nível de 
serviço para atender às entregas de encomenda. Mas de onde você deduziu 
que quatro horas é um tempo suficiente? Você sabe quais são os destinos das 
entregas? Você sabe quantas entregas terá que fazer por dia? Você sabe qual 
meio de transporte poderá usar para fazê-las? Você sabe qual é o tamanho 
dos pacotes que terá que entregar? Se qualquer uma das questões acima não 
tiver uma resposta positiva com números reais conhecidos, então seu com- 
promisso de entrega em quatro horas é uma mera especulação. Nada garante 
que você possa cumpri-lo. 

Muitos provedores de serviços de TI têm assumido ANS nas mesmas 
condições. Estabelecem prazos para atendimento, porém não sabem se 
efetivamente conseguirão cumpri-los. Estabelecem disponibilidades para 
serviços que não saberão se conseguirão disponibilizar, pois dependem de 
uma cadeia de provedores de bens e serviços que não está sequer mapeada 
no CMDB. 

Para conseguir estabelecer ANS realistas e exequíveis é necessário que se 
conheça uma série de variáveis: quantidade de usuários a atender, distribui- 
ção geográfica dos atendimentos, complexidade das atividades, tamanho da 
equipe, tecnologias envolvidas, entre tantas outras. Uma variável adicional 
que é muito importante e pouco referenciada é o modo de execução das 
atividades solicitadas. O que significa? Que não podemos efetivamente nos 
comprometer em executar uma atividade em um determinado tempo se não 


temos um padrão de execução de atividades. 
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Quantidade de usuários 

Distribuição geográfica 

Complexidade das atividades Acordo de Nível de 
Serviço 

Tamanho da equipe 

Tecnologias envolvidas 


Realista e exequível 


Imagine uma situação na qual um usuário solicite que sua máquina te- 
nha um sistema operacional atualizado por um mais recente. Em quanto 
tempo podemos prometer que um técnico executará esta atividade? A res- 
posta para essa pergunta só poderá ser definida se soubermos como isso 
será feito. Imagine que tenhamos dois técnicos e que cada um tenha uma 
preferência pessoal por um método para executar a atividade. Um deles 
pode escolher o método de formatação da máquina e reinstalação total de 
tudo o que havia nela. Já o outro pode pensar em instalar outro sistema 
operacional em outra partição e manter os dois sistemas simultaneamen- 
te, desativando futuramente o primeiro. Fica claro que se os dois usaram 
métodos muito diferentes então teremos tempos consumidos muito dife- 
rentes. Tanto podemos gastar 30 minutos como gastar três horas. Se não 
tivermos uma padronização de procedimentos definidos para atuação da 
equipe técnica, como poderemos definir tempos padronizados para execu- 
ção das atividades? 

Outra variável que pode tornar impossível medir os tempos de atuação 
dentro de um ANS é o fato de que muitas atividades, para serem executa- 
das, dependem de intervenções de terceiros, e que ANO (Acordos de Nível 
Operacional) e contratos de apoio não têm seus tempos definidos de modo 


equivalente. 
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Pode ser impossível cumprir um prazo de execução de uma atividade de 
duas horas se dependermos de terceiros que nos impõem tempos superiores 
a isso, ou pior, se nem sabemos em que tempo estes terceiros nos atende- 
rão. Muitas vezes, nestes casos, surge o “recurso de interrupção do tempo 
de SLA” enquanto o chamado está sendo atendido. Esta é uma prática 
usada por muitas empresas que prometem que um chamado será atendido 
em duas horas e depois descobrem que dependem de um terceiro que levará 
três horas para executar uma atividade intermediária. Assim, após o prove- 
dor de serviços de TI ter trabalhado uma hora, ele repassa o chamado para 
o terceiro, interrompe a contagem de tempo, espera três horas pela inter- 
venção externa, recebe o chamado de volta, libera novamente a contagem 
do tempo e encerra o chamado com 1h10 de “tempo transcorrido”, cum- 
prindo o SLA. A única questão que resta é justificar para o solicitante por 
que seu chamado que foi aberto às 8h da manhã e foi encerrado às 12h10 
teve somente 1h10 de duração registrada. Quem entende isso? Como po- 
deremos explicar que, se alguém ficou 4h10 sem poder imprimir relatórios, 
nós temos um indicador informando que a indisponibilidade do serviço foi 
de somente 1h10? 


08:00 09:00 10:00 12:00 12:10 
Prazo = 2h 


Provedor = 1h 


Provedor = 0h10 


Terceiro = 3h (TEMPO INTERROMPIDO) 


LIÇÕES APRENDIDAS: Um ANS é um acordo que deve equilibrar demandas e 
ofertas, mas também benefícios e custos. Procure colocar-se como o facilitador 
para obtenção deste acordo e não como o determinador das variáveis. Elas não 


pertencem a Tl. São inerentes ao ambiente organizacional. 
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COMO MANTER UM ANS? 


Supondo que o primeiro desafio de elaborar um ANS tenha sido trans- 
posto, resta-nos ainda uma próxima fase, tão ou mais desafiadora que a pri- 
meira: manter o ANS criado. Esta fase é desafiadora porque ao se falar em 


manter um ANS nós temos alguns aspectos a serem considerados. 


DESAFIO 1: DESAFIO 2: DESAFIO 3: DESAFIO 4: 


Manter em Comprovação Busca de Confrontação 
uso da validade consenso de prev. x real 


O primeiro desafio relativo à manutenção de um ANS é mantê-lo em uso, 
ou seja, preservar sua aplicação na íntegra. Muitas pessoas podem até pensar 
que manter um ANS não é assim tão difícil porque uma das condições que 
ele estabelece são os prazos, que são associados ao atendimento dos chama- 
dos registrados e que o próprio cliente teria interesse em mantê-los ativos. 
Realmente, este modo de ver a questão está correto. Esta pequena parte do 
ANS é sempre lembrada pelos clientes e cobrada da TI. Mas e o que dizer do 
resto do ANS? Será que as condições e responsabilidades estabelecidas para 
os clientes no ANS serão facilmente mantidas? Nem sempre. 

Existem clientes que deixarão de lembrar de suas responsabilidades, tais 
como: não omitir informações críticas para a resolução dos chamados, não 
alterar configurações dos equipamentos sem autorização da TI, não instalar 
softwares, não estabelecer prioridades irreais para suas demandas etc. 

Uma das estratégias sugeridas na própria ITILº é realizar revisões perió- 
dicas do ANS. Isso não significa necessariamente que estas revisões precisem 
alterar prazos, condições e regras a cada período. Elas podem servir para 
demonstrarmos, por exemplo, como as partes do acordo vêm cumprindo 
suas obrigações e exercendo seus direitos. É muito comum, nestas reuniões, 


ver o cliente fazendo cobranças do provedor de serviços de TI quanto ao 
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cumprimento dos prazos de atendimento. Por que, então, a TI, nesta mesma 
reunião, não apresenta seus números e justifica que alguns indicadores não 
foram atingidos porque o próprio cliente não cumpriu sua parte no acordo? 

Por exemplo, um chamado que deveria ter sido atendido dentro de um 
prazo X teve o dobro do tempo gasto para sua resolução porque o cliente 
omitiu a informação de que tinha instalado um software sem autorização na 
máquina, o que fez com que o técnico gastasse muito mais tempo do que o 
previsto no diagnóstico e resolução do problema. Seria uma surpresa para o 
cliente, sem dúvida, se pudéssemos dizer que, neste caso, o prazo prometido 
no ANS não teria mais valia, pois as condições de execução da tarefa não 
tinham sido também asseguradas ao técnico. É como se a “garantia de prazo 
de atendimento” dada pela TI tivesse sido “perdida” porque o cliente violou 
o acordo. 

Outro desafio relativo à manutenção de um ANS é a efetiva comprovação 
de que os prazos e demais condições nele estabelecidos continuam válidos 
após um período de mudanças no contexto empresarial. Lembre-se de que 
muitos dos requisitos de disponibilidade, de capacidade, de segurança, entre 
outros, podem ter se alterado durante um último período de análise. A dis- 
ponibilidade prometida quando o ANS foi criado talvez hoje não seja mais 
suficiente para o cliente, ou pelo contrário, talvez seja agora até desnecessá- 
ria, pois os processos da área de negócio foram alterados e a demanda talvez 
tenha diminuído. 

Avaliar todos estes aspectos requer, então, uma primeira iniciativa: a co- 
leta de informações nos demais processos. Se o processo de gestão de capaci- 
dade, de gestão de disponibilidade, de gestão de demanda e de gestão de re- 
lacionamento com o negócio, não caminharem em conjunto com o processo 
de gestão de nível de serviço, não teremos como proceder a uma análise real 
para avaliação das condições de manutenção do atual ANS. 

Um terceiro desafio na manutenção do ANS diz respeito à mesma di- 
ficuldade já encontrada em sua elaboração: a busca de consenso entre os 
clientes da TI. Lembre-se de que qualquer renegociação de condições de 


um ANS com um cliente, seja “para cima” ou “para baixo”, poderá afetar 
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diretamente os ANS com as demais áreas, gerando o que podemos chamar 
de um “efeito dominó cíclico”, ou seja, cada alteração em um ANS poderá se 
refletir nos demais e assim por diante indefinidamente, voltando inclusive a 
afetar o primeiro ANS mudado. 

Se, por exemplo, um ANS foi renegociado para fornecer maior capaci- 
dade e disponibilidade para um determinado serviço, esta mudança poderá 
exigir que outros ANS reduzam suas capacidades e disponibilidades propor- 
cionalmente, de modo a manter o equilíbrio entre os recursos oferecidos pela 
TI e os recursos aplicados ao atendimento dos ANS. Fica claro que a rotina 
de revisão e manutenção de ANS em um ambiente já estabilizado, apesar de 
necessária e recomendada para busca de melhorias contínuas, pode significar 
um instante de razoável complexidade, podendo, inclusive, voltar a gerar 
necessidades de renegociações múltiplas e busca de consenso, o que, sem 
dúvida, não é um objetivo fácil de ser atingido. 

Vale a pena destacar aqui que quando falamos em revisar o ANS, não es- 
tamos apenas nos referindo ao processo de confrontar os níveis estabelecidos 
com os níveis alcançados, mas também na redefinição dos níveis a alcançar. 
É verdade que os níveis alcançados poderão, sim, servir de subsídio para 
a renegociação. Caso os níveis estabelecidos sejam irreais ou inatingíveis, 
quer por terem sido criados sem critérios adequados, quer pelo ambiente ter 
se modificado durante o último período, será vital contar com dados para 
direcionar a definição de novas metas. À confrontação é, na verdade, um 
processo que precede a revisão e que, conforme os resultados apresentados, 
pode inclusive demonstrar que as condições atualmente estabelecidas no 
ANS são suficientes e não precisam ser alteradas. Isso não significa que não 
precisaremos fazer a revisão, mas sim que ela deverá ser feita para atualizar 
ou para reafirmar as condições preexistentes e também os compromissos e 
responsabilidades. 

A confrontação de níveis de serviço estabelecidos com os alcançados é 
também, em si, outro desafio a ser enfrentado. Grande parte dos proje- 
tos compara algo muito simples e, portanto, impreciso: os prazos de aten- 


dimento dos chamados. Na maioria dos casos, somente se compara se os 
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chamados de determinada prioridade foram atendidos dentro do prazo pro- 
metido. Se o prazo foi respeitado, se diz que o “SLA foi atendido”, caso 
contrário, que o “SLA não foi atendido”. Já vimos que este conceito pode 
produzir cenários que induzirão ao erro. Porém, a questão é ainda mais 
complexa se pensarmos que temos outra variável a ser considerada quando 
falamos em tempo de indisponibilidade de um serviço. Sim, se o SLA está 
associado a uma disponibilidade de um serviço em um determinado tempo, 
então teremos que calcular qual foi a indisponibilidade total gerada pelas 
diversas interrupções atendidas para aquele serviço, o que não é fácil. Veja 
o cenário a seguir: 

Tivemos num certo mês um conjunto de chamados que afetaram o ser- 
viço de correio eletrônico em diferentes filiais, mas todas pertencentes ao 
departamento de vendas. Logo, nosso SLA para o serviço de correio eletrô- 
nico do cliente “departamento de vendas” será afetado ao final do mês, pois 
uma indisponibilidade será gerada para o serviço. Vamos isolar um único dia 
deste período para fazer uma análise da indisponibilidade real gerada pelos 


incidentes. 


Departamento de Vendas A g A 
Filial C Filial D 
Filial L 7 L_z 
A Filial B Filial E 


Sejam cinco incidentes reportados para o serviço de correio eletrônico por 
diferentes filiais com as seguintes características: 

A filial A reporta a indisponibilidade do correio eletrônico às 9h da ma- 
nhã, quando tenta abrir os e-mails recebidos na noite anterior e precisa 


aguardar até as 13h quando o serviço é restabelecido. 
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A filial B reporta a indisponibilidade somente às 11h da manhã, quando 
tenta ler e-mails baixados no dia anterior, pois até este horário não havia 
percebido que o correio eletrônico não estava funcionando. 

A filial C reporta a indisponibilidade às 10h da manhã, quando tenta en- 
viar um e-mail para a matriz e percebe que o serviço está parado. 

Também no período da tarde volta a ocorrer outra interrupção do serviço 
de correio eletrônico por outro motivo (o link caiu), afetando a filial D das 
14h às 17h. 

A filial E só percebe a falha às 16h e registra um novo incidente que acaba 
sendo encerrado às 17h, quando o serviço é restabelecido. 

Se colocarmos num gráfico todos os incidentes registrados e atendidos, 


teremos algo como mostrado abaixo: 


FIGURA 12 
Incidentes afetando o serviço de correio 
eletrônico no Depto. de Vendas 


Filial | 08:00 | 09:00 | 10:00 | 11:00 | 12:00 | 13:00 | 14:00 | 15:00 | 16:00 | 17:00 | 18:00 


A 


Serviço restabelecido 
Serviço restabelecido 


Se simplesmente somássemos o tempo de parada de cada um dos inci- 


dentes teríamos: 
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TABELA 2 

Filial Tempo gasto Prazo Resultado 
A 4 horas 4 horas No prazo 

B 2 horas 4 horas No prazo 
C 3 horas 4 horas No prazo 

D 3 horas 4 horas No prazo 

E 1 horas 4 horas No prazo 
TOTAL 13 horas 


Isso poderia nos dar a primeira visão de que tivemos 13 horas de in- 
disponibilidade para o serviço de correio eletrônico neste ANS. Porém, se 
analisarmos a temporalidade em que os incidentes foram reportados por di- 
ferentes usuários, veremos que houve sobreposições de indisponibilidades 
do serviço. No mesmo horário em que o serviço estava indisponível para 
uma filial, também estava em outra. Isso significa que a indisponibilidade 
total não foi de 13 horas, mas somente de 7 horas (veja na Figura 12). Logo, 
percebe-se que somar os tempos de atendimento de cada um dos chamados 
não seria uma regra válida. 

Acontece que a maioria das ferramentas de confrontação de níveis de 
serviço não é capaz de fazer esta análise temporal sobrepondo os incidentes 
de modo a perceber a simultaneidade dos efeitos de indisponibilidade entre 
eles. Fica evidente que boa parte das negociações de níveis de serviço pode 
estar confrontando números imprecisos que muitas vezes irão penalizar os 
prestadores de serviços por não considerar o fator redutor de tempo de inter- 
rupção que as sobreposições geram. 

Talvez seja por toda esta complexidade de análise que muitos acabem, in- 
tencionalmente ou não, restringindo-se a comparar simplesmente se o prazo 
de atendimento individual de um chamado foi atendido ou não. Aplica-se 
a regra de que “se não se pode calcular de modo exato, então se calcula do 
modo mais simples possível”. Assume-se assim que, de qualquer modo, al- 


gum tipo de erro já estará mesmo presente no processo. 
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Outros cenários podem também ser reproduzidos para mostrar que a so- 
matória dos tempos de cada incidente que afetam um serviço não pode ser 
sempre usada como base para cálculo da indisponibilidade de um serviço. 
Ainda outro fator mais complexo pode tornar o cálculo da indisponibilidade 
de um serviço uma tarefa quase impossível de ser realizada com precisão. 
Imagine outro cenário: 

Temos um serviço de pagamento on-line sendo usado pela filial A. Nesta 
são reportados 5 incidentes de diferentes tipos e naturezas, conforme abaixo: 


TABELA 3 
Incidente | Tipo Natureza | Duração 
1 Micro da agência não liga Hardware 2 horas 
local 
2 Browser para acesso à web está desconfigurado | Software 1 hora 
básico 
3 Firewall não permite acesso à página desejada Software 2 horas 
de rede 
4 Falta de energia na filial Energia 3 horas 
5 Aplicação de pagamentos on-line não permite Aplicativo 2 horas 
login 
TOTAL DE INDISPONIBILIDADE NA FILIAL 10 horas 


Perceba que todos os incidentes, mesmo sendo de tipos e naturezas dis- 
tintas, acabaram por afetar o mesmo serviço: “O pagamento on-line.” O mi- 
cro que não ligava, a falta de energia na filial e todos os outros problemas 
com o browser e com o firewall impediram que a filial utilizasse o serviço de 
pagamento on-line. No final do mês, deveríamos ter condições de apontar 
todas as 10 horas para o mesmo ANS do mesmo serviço. Para isso, teríamos 
que ter coletado a informação de qual era o serviço afetado (e não o item de 
configuração afetado) em cada um dos incidentes. Porém, sabemos que isso 


nem sempre é feito. 
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Imagine agora que, além de conseguir agrupar estes diferentes incidentes 
em torno do mesmo serviço, ainda tivéssemos que analisar a sobreposição 
temporal vista no cenário anterior. Talvez descobríssemos que a sobreposi- 
ção reduziria o total de horas de indisponibilidade de 10 horas para 9 horas 
caso dois dos incidentes tivessem ocorrido simultaneamente (o firewall blo- 
queado e o browser desconfigurado). 

É possível perceber através de todos estes cenários que a própria apuração 
dos níveis de serviço oferecidos já apresenta suas dificuldades inerentes. O 
que dizer então da dificuldade da própria área de negócio em estabelecer o 
real nível de serviço que ela demanda? Podemos imaginar que se uma área de 
negócios não possuir um conhecimento preciso de seus processos de negócio, 
ela tenderá a estabelecer sempre níveis de serviço muito mais críticos do que 
realmente precisa. 

Se nem o nível de serviço requerido for corretamente definido, então de 
que adiantará buscarmos uma precisão no levantamento do nível de serviço 
oferecido? Mesmo que consigamos uma precisão no levantamento dos níveis 
de serviço oferecidos, o que representará um não atingimento dos níveis re- 
queridos? Será que mesmo não tendo atingido os níveis pedidos, a TI não 
teria provido um servido suficientemente bom, não tendo prejudicado, por- 
tanto, os processos de negócio que o cliente executa? 

Por outro lado, quando tivesse atingido o nível de serviço requerido, teria 
a TI cumprido os requisitos necessários ou simplesmente oferecido muito 
mais do que o necessário? Atingir ou não um nível de serviço deveria re- 
presentar muito mais do que igualar ou superar metas estabelecidas, mas 
sim oferecer recursos suficientes para que as áreas de negócio cumpram seus 
papéis na organização. Afinal, o que é mesmo um serviço? E por que a TI o 
oferece? 

Quando estudamos a gestão de capacidade vemos que devemos dimen- 
sionar e monitorar a capacidade do negócio, dos serviços e dos componentes. 
Será que esta mesma abordagem, se usada no processo de gestão de nível de 
serviço, poderia dar origem a novos conceitos tais como gestão de nível de 


negócio e gestão de nível de componente? E algo a se pensar. 
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LIÇÕES APRENDIDAS: Um ANS criado adequadamente terá muito menos dificul- 
dade em ser mantido. Você não precisa oferecer mais do que as áreas necessi- 
tam, mas se oferecer terá que entregar. A discussão sobre atingir ou não o nível 
de serviço requerido é algo muito mais complexo do que parece. Devemos usar 
o bom senso na aplicação de regras e critérios sempre destacando a importância 
de atender os “níveis de negócio”, ou seja, alcançar os resultados que o negócio 
demanda. 


COMO DIVULGAR UM ANS? 


Quando falamos em divulgar um ANS temos três instantes importantes a 
analisar: sua divulgação antes de ele ser criado, sua divulgação enquanto está 
sendo criado e sua divulgação após ter sido criado. Vejamos a seguir cada um 


destes instantes. 


ANTES DA CRIAÇÃO DURANTE A CRIAÇÃO APÓS A CRIAÇÃO 


Divulgação antes de ele ser criado 


O ANS é um artefato essencial no estabelecimento da relação entre TI 
e clientes, como já vimos. É o vínculo que une os interesses e cria respon- 
sabilidades e direitos entre as partes. Divulgar sua finalidade, abrangência, 
cobertura, estrutura, suas implicações de uso etc., antes de ele ser negociado e 
criado, poderá permitir que as pessoas realmente compreendam o papel que 
ele representa. Poderá principalmente admitir que o processo de negociação 
se inicie estando todos cientes de aonde queremos chegar e de até onde po- 


deremos chegar. 
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Durante o processo de criação do ANS deveremos ter, além da interação 
entre a TI e o cliente, a interação entre os clientes. Imagine então o que po- 
deria acontecer se os diversos clientes tivessem expectativas diferentes em re- 
lação ao produto que será gerado por estas interações. Como conseguiríamos 
uma convergência para um ponto comum se cada um tivesse um conceito 
diferente sobre o seu ANS e sobre os ANS das demais áreas? Como conse- 
guiríamos fazer com que cada área interpretasse os ANS das demais áreas e 
pudesse compará-los com seu próprio? 

Quando e como, então, poderíamos divulgar este tipo de informação? A 
sugestão é que isso ocorra já no início do processo de implantação da GSTI. 
Já mostramos no Capítulo 1 que o envolvimento da organização no processo 
de implantação da GSTI é essencial. Portanto, realizar um programa de re- 
passe de informações sobre a GSTI, e não sobre a ITIL®, sem o uso de mui- 
to “informatiquês”, logo que se defina que usaremos este tipo de abordagem, 
pode permitir que repassemos os conceitos de serviços, de GSTI, de ANS, e 
tantos outros essenciais. 

Não se trata de realizar um curso completo de ITIL Foundationsº para 
os clientes, mas de executar, talvez, um seminário sobre GSTI que seja fo- 
cado no público-alvo, com adequadas linguagem e profundidade de conhe- 
cimento. Esta iniciativa terá que ser complementada com uma boa revisão 
de conceitos feita antes do início das negociações para criação do ANS. Não 
acredite que somente um repasse inicial vai fixar todas as ideias necessárias. 
Ele poderá servir para criar uma nova visão sobre a GSTI entre os clientes, 
mas, muito provavelmente, terá perdido boa parte de seu conteúdo até que a 
fase de criação dos ANS se inicie, pois, como já vimos, teremos várias outras 
coisas a serem feitas antes. 

Estando todos cientes do que representa um ANS, poderemos iniciar 
sua negociação e criação. Neste instante, é essencial também que toda a or- 
ganização esteja ciente dos ANS que serão definidos, de qual abordagem 
usaremos para criá-lo, de quais áreas serão envolvidas e em que sequência o 
trabalho será feito. Isso dará a oportunidade a todos os envolvidos de conhe- 
cerem os resultados que estão sendo produzidos e até de contribuírem com 


melhorias já neste instante. 
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Divulgação enquanto ele está sendo criado 


Quando abordamos o processo de criação do ANS já vimos que uma das 
alternativas para produzir bons ANS é tentar realizar um trabalho integra- 
do entre o provedor de serviços e as diversas áreas de negócio. Se adotar- 
mos esta estratégia, então deveremos, já durante o processo de criação de 
um ANS com uma área de negócio específica, estar contrapondo este novo 
ANS com os já existentes, quer seja para adotar os mesmos padrões, quer 
seja para demonstrar que, devido a compromissos já assumidos previamen- 
te, os níveis de serviços requeridos por este novo ANS não serão possíveis 
de serem atendidos. 

Este trabalho contínuo de confrontação de novos requisitos com os já 
atendidos previamente pode contribuir de modo muito eficiente para a de- 
terminação futura de níveis de serviço mais realistas. Sem conhecer o quanto 
já está comprometida nossa capacidade de atendimento de níveis de serviço, 
como poderemos assegurar que novos compromissos poderão ser realmente 
atendidos? Fica, portanto, implícito que o processo de criação de um novo 
ANS pode requerer validações intermediárias deste acordo não só com a 
área requerente, mas também com as demais áreas. Será nestas validações 
que poderemos, inclusive, demonstrar a todas as áreas que os recursos que 
a TI detém são limitados, e que só com um critério de alocação equilibrado 
poderemos atender a todos. 

A TI, então, durante o processo de criação de um novo ANS, não terá 
sozinha a responsabilidade de afirmar se pode ou não atender a todos os 
requisitos que está recebendo de uma área de negócio. Ela deverá ser, sim, 
a mediadora entre a alocação destes recursos na exata medida em que as de- 
mais áreas entendam que isso é pertinente e factível para a organização. Não 
se trata de querer atender a uma área, mas sim de poder dispor dos recursos 
para atendê-la, seja pela incorporação ou pela realocação de recursos já des- 
tinados a outras áreas. 

Este modelo se reflete muito bem, por exemplo, quando se fala em dispor 
de técnicos para atendimento VIP a uma área. Se temos um time de cinco 


técnicos que podemos alocar de modo dedicado para atendimento a diversas 
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áreas de negócio, e uma determinada área, por se considerar crítica (ou seria 
VIP?), requerer a alocação de dois técnicos dedicados ao seu atendimento, 
então poderá chegar o dia em que outra área também requeira um atendi- 
mento dedicado e que a TI defina que isso só será viável se a área que hoje já 
possui dois técnicos ceda um para a solicitante. Esta mesma realidade pode 
ocorrer com outros recursos limitados, tais como espaço em disco, horas- 
homem para desenvolvimento de projetos etc. 

Se as áreas não compartilharem entre si suas demandas, seus fatores críti- 
cos de sucesso, seus processos essenciais, seu padrão de atividade de negócio, 
será muito difícil conseguir estabelecer um padrão de avaliação equilibrado 
para estas situações de conflito de recursos. Todas estas características e in- 


formações precisam ser compartilhadas com os clientes durante a fase de 


elaboração do ANS. 


Divulgação após ele ter sido criado 


Independentemente dos tipos de ANS definidos (por cliente, por servi- 
ço ou multinível), não há qualquer motivo para que eles não sejam ampla- 
mente divulgados para toda a organização depois de criados. Muito pelo 
contrário. 

Muitas pessoas podem acreditar que, por se tratar, às vezes, de um acordo 
realizado entre uma área de negócio e um provedor de serviços, seriam estes 
acordos um instrumento particular entre as partes. Teriam um caráter quase 
sigiloso, pois definiriam requisitos associados a uma área de negócio que não 
deveriam ser tornados públicos para as demais áreas. Entretanto, devemos 
lembrar que não estamos falando de tornar públicas as regras de negócio de 
uma área, e sim de divulgar os requisitos que o provedor de serviço de TI 
deve atender para ela. Podemos até estar expondo os critérios de capacidade, 
disponibilidade e segurança necessários para um serviço, mas não exatamen- 
te os detalhes de uso do próprio serviço. 

Podemos, certamente, ter diversos benefícios pela divulgação destes 


ANS. O primeiro benefício direto é a confrontação dos níveis de serviços 
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definidos por cada área de negócio com os demais níveis de serviços das 
demais áreas. Como já dissemos, somente com o mútuo conhecimento das 
demandas e dos requisitos de atendimento poderemos ter maior equilíbrio 
entre os critérios a serem adotados. Racional ou irracionalmente, as áreas 
passam a ser mais comedidas nas suas “exigências de nível de serviço” se 
sabem que terão seus ANS publicados e conhecidos pelas demais áreas, 
principalmente pelas hierarquicamente superiores. Este pode ser um ele- 
mento, como diz a ITIL®, para “influenciar a demanda” das áreas, a nosso 
favor, é claro. 

Outro aspecto da divulgação pós-criação é a apresentação não só dos re- 
quisitos dos ANS, mas também dos indicadores de cumprimento, ou não, 
das metas estabelecidas. Algumas pessoas podem novamente imaginar que 
os resultados da confrontação entre metas estabelecidas e metas alcançadas 
poderiam ser somente pertinentes à área afetada pelo ANS. É verdade que a 
área diretamente afetada pelo ANS deve ser a primeira a ter interesse nesta 
confrontação, mas poderemos tirar também proveito desta informação para 
outras finalidades. 

Um primeiro benefício que podemos obter pela divulgação dos ANS en- 
tre as áreas é permitir que exista a equalização das distorções. Se partirmos 
do princípio de que todos os ANS foram concebidos através de um processo 
estruturado e justo, considerando a capacidade e disponibilidade real que 
pode ser prometida aos clientes, e que os melhores esforços foram realizados 
para conceber processos de GSTI adequados, então é de se esperar que os 
ANS possam ser atendidos pela TI sem grandes desvios. 

Porém, alguns eventuais desvios podem ocorrer e comprometer o aten- 
dimento dos ANS criados. Se uma área tivesse somente um ANS, por 
exemplo, e este não fosse atendido num determinado mês, poderíamos 
estar transmitindo para tal área a falsa noção de que o desempenho da TI 
não foi adequado naquele período, pois este seria um dado isolado. Já se 
pudermos dar uma visão global de todos os ANS atendidos no período em 
contraposição à somente aquele ANS não atendido, poderemos então mi- 
nimizar o impacto à imagem da TI. Isso é o que chamamos de equalização 


do desempenho. 
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Outro benefício da comparação de desempenho entre as diversas áreas é 
conseguir estabelecer um padrão de referência. Imagine que a área que não 
teve seu ANS atingido possa comparar os requisitos de nível de serviço com 
as demais áreas e perceber que o descumprimento se deu, não por deficiência 
da TI, mas sim por critérios superdimensionados pela própria área. É verda- 
de que cada diferente área pode ter um critério próprio ligado a seus proces- 
sos de negócio que podem ser totalmente diferentes das demais. Entretanto, 
mais do que analisar as diferenças, nós deveríamos analisar as igualdades em 


busca de um padrão de atendimento mais homogêneo. 


LIÇÕES APRENDIDAS: A comunicação é um princípio essencial da GSTI. O des- 
conhecimento da finalidade, das condições, das restrições, dos benefícios, dos 
riscos etc. durante todo o ciclo de vida do ANS pode criar resistências desne- 
cessárias à sua criação, adoção e manutenção. Divulgar resultados também é um 
meio de buscar a equalização de demandas e desempenho. 


QUANDO ESTARÁ TERMINADO UM ANS? 


Podemos até falar em terminar a elaboração de um ANS, mas a verdade 
é que, por se tratar de um artefato aplicado ao dia a dia da GSTT, nunca 
poderemos deixar de mantê-lo em sincronismo com a realidade das áreas de 
negócio. Como sabemos que as organizações vivem em constante transfor- 
mação, então é de se esperar também que os ANS estejam constantemente 
requerendo revisões, renegociações e reelaborações. A própria ITILO cita 
que, no mínimo trimestralmente, um ANS deveria ser revisto. Isso não sig- 
nifica necessariamente que ele será alterado a cada revisão, mas, com certeza, 
se utilizarmos as estratégias que já citamos anteriormente, de confronto de 
demandas entre áreas, será possível que algum tipo de mudança nos níveis de 


serviço seja detectado, para mais ou para menos. 
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O conceito então mais adequado seria o de ciclo de vida do ANS, baseado 
em planejamento, criação, avaliação e revisão. A cada ciclo destes, o ANS se- 
ria aprimorado espelhando mais fielmente as necessidades da área cliente e o 
potencial de atendimento do provedor de serviços. Se você observar este ciclo 
verá que ele se baseia no ciclo de Deming (PDCA), criando um processo de 
melhoria contínua para o artefato chamado ANS. 

Se considerarmos que a cada ciclo de melhorias está associado um novo 
estágio de maturidade, nós poderemos definir que um ANS não tem um 
fim, mas estágios de maturidade. Esta visão pode e deve ser transmitida aos 
clientes. À primeira finalidade de transmitir tal conceito é mostrar que um 
ANS será gradativamente alterado a cada revisão, não porque esteja errado 
ou porque seja ruim para qualquer das partes. À ideia de melhoria contínua 
mostra que ele já pode estar adequado ou já pode ser bom para as partes, mas 


que mesmo assim podemos buscar melhorias. 


Plan: definir as estratégias de 


criação do ANS Ra 


Act: elaborar ajustes no Do: criar o ANS 


ANS 
Check: confrontar os ANS Fa 


alcançados com os previstos 


Toda a ITILº se baseia neste princípio: é melhor iniciarmos com um 
nível de maturidade menor e gradativamente irmos agregando melhorias do 
que tentar estabelecer um grau de maturidade muito alto de modo precoce, 
frustrando nossos clientes. Este mesmo princípio também se aplicará aos 
artefatos que já citamos: o CMDB, o catálogo de serviços, os ANS, e assim 


por diante. 
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LIÇÕES APRENDIDAS: Procure envolver seus clientes em todas as fases do PDCA 
associado ao ANS. Se eles tiverem comprometimento com o planejamento, cria- 
ção, implantação e validação, as propostas de ajustes surgirão naturalmente e a 
resistência às suas implementações serão menores. 


QUAIS SÃO AS PRINCIPAIS FALHAS AO SE CRIAR 
E MANTER UM ANS? 


A ideia de que podemos aplicar um processo de melhoria contínua nos 
ANS que criaremos pode levar algumas pessoas a pensar que talvez, então, 
não seja assim tão difícil criá-los e mantê-los. Pensam que o processo de me- 
lhoria contínua será capaz de corrigir (ou melhorar) qualquer característica 
associada ao ANS. Seria isso verdade? Vamos ver alguns pontos que podem 
esclarecer a questão: 


CONCEITOS SIMPLIFICAÇÃO MANIPULAÇÃO 


Conceitos 


Quando falamos em revisões de um ANS, estamos pensando sempre em 
realizar ajustes nas suas características: regras, responsabilidades, capacida- 
des, disponibilidades, segurança, prazos, configurações etc. Porém, se desde 
a criação do ANS tivermos conceitos mal estabelecidos, dificilmente pode- 
remos revertê-los ao longo do tempo. 

Por exemplo, se alguém não entender a finalidade do ANS e os papéis que 
devem ser exercidos pelas partes, poderemos tentar mudar depois quaisquer 


variáveis do ANS e nunca teremos um acordo que deixe as partes satisfeitas. 
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À própria negociação de mudanças nas variáveis do ANS poderá ser contes- 
tada, pois as pessoas não estarão convencidas dos objetivos das mudanças. 
Renegociar ou amadurecer conceitos pode gerar um ambiente confu- 
so para aqueles que já vêm praticando processos com os conceitos atuais. 
É importante que desde a fase inicial todos os conceitos sejam claramente 
abordados (mesmo que não totalmente implantados) para que, futuramente, 
possam ser incorporados aos processos definidos. Processos podem ser ama- 


durecidos, conceitos não. 


Simplificação 


A simplificação que muitos fazem ao afirmar que um ANS é traduzido 
por um tempo de execução de uma tarefa acaba criando para os clientes 
um sentimento de cobrança de prazos unilateral. A falha em transmitir aos 
clientes o real conceito de um ANS é muitas vezes da própria equipe da TI 
que, não querendo mudar paradigmas já existentes para “facilitar a adoção 
da ITILº”, procura minimizar os reflexos das mudanças necessárias para o 
cliente. 

Criar um ANS simples não significa criar um ANS com a ausência de 
conceitos essenciais ou com a mudança nos conceitos para evitar conflitos. 
A simplificação pode ser feita no escopo, na definição de regras, no envolvi- 
mento de menor número de fatores para avaliação ou definição de priorida- 
des, na generalização de requisitos, no uso de ANS por serviço e por cliente, 


e por aí afora. 


Manipulação 


Muitas vezes, como consequência da falta de conceitos e da simplifica- 
ção, encontramos empresas nas quais os números associados aos ANS são 
manipulados de modo a demonstrar muitas coisas, menos o nível de serviço 


entregue. 
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Um conceito equivocado que leva a isso é a ideia de que o que deve ser 
medido é o “serviço prestado pela TT”. Se o que você deseja medir não é a 
disponibilidade do serviço entregue, mas sim a rapidez dos serviços execu- 
tados (atividades executadas pela TT), então realmente você deveria medir 
somente o tempo que os técnicos têm gastado no atendimento das diversas 
solicitações recebidas. Assim surge uma manipulação muito frequentemente 
vista em boa parte das empresas: a parada de contagem de tempo durante o 
atendimento de uma solicitação ou incidente. Mas por que parar a contagem 
de tempo? Quem confiaria em um ANS com um prazo de atendimento no 
qual se permite parar a contagem do tempo? 

Realmente, para uma medição de um ANS, associado a tempos de dispo- 
nibilidade de um serviço, não faria o menor sentido termos interrupções de 
contagem de tempo durante a fase de reparo e restauração do serviço. Se um 
serviço foi interrompido às 8h e somente foi restaurado às 18h, não há como 
afirmarmos que sua indisponibilidade não foi de 10 horas. 

Já se o seu ANS está preocupado em medir os tempos de atuação de sua 
equipe técnica (pois quer medir serviços executados e não serviços entre- 
gues), então você até poderia usar a estratégia de “parar o relógio”. Você po- 
deria medir e provar que seu técnico trabalhou somente seis horas no período 
das 8h até as 18h pois teve duas horas de deslocamento e mais duas horas 
esperando pelo retorno de uma informação do cliente. Logo, a presteza do 
técnico poderá ser avaliada como “seis horas para atender o cliente”, mesmo 


que o cliente tenha ficado 10 horas sem o serviço. 


08:00 10:00 12:00 18:00 


Serviço interrompido = 10h 


Deslocamento = 2h 


Aguardando inf. = 2h 


Atuação técnica = 6h 
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Não há problemas em fazer esses dois tipos de medição, desde que cada 
um deles seja utilizado para uma finalidade diferente. Medir o tempo de 
indisponibilidade do serviço (10 horas), neste nosso exemplo, deveria servir 
para nos indicar a necessidade de melhores processos e configurações para 
prover um serviço mais resiliente e com maior facilidade de manutenção. 
Já medir o tempo de atuação do técnico (seis horas) deveria servir para nos 
indicar que a produtividade ou nível de expertise do técnico está adequada, 
sendo este último indicador uma informação só pertinente ao próprio gestor 
da equipe técnica. 

O problema surge quando o último número medido (seis horas) é usado 
para demonstrar ao cliente que a qualidade do serviço entregue está atenden- 
do aos requisitos do negócio. Dez horas de um serviço parado impactarão o 
cliente de um modo, enquanto seis horas impactariam de outro modo. Se 
procurarmos demonstrar que gastamos só seis horas na recuperação deste 
serviço estaremos desprezando quatro horas de impacto real gerado ao clien- 
te. Este tipo de manipulação de informações não nos levará muito longe, 
pois tentaremos apresentar números que não traduzirão a real visão do clien- 
te junto ao seu processo de negócio. 

Poderemos ter indicadores para demonstrar que a TI tem executado suas 
funções de modo satisfatório, mas, por outro lado, teremos clientes insatis- 
feitos com o desempenho da TI, sendo que nenhuma das partes está errada 


na visão que tem. 


LIÇÕES APRENDIDAS: Crie condições para que todos os envolvidos com o pro- 
cesso de estabelecimento de um ANS tenham desde o início a compreensão dos 
conceitos, da finalidade, dos benefícios e do modo de aplicação deste acordo. 
Não deixe de expor todos os conceitos de modo bastante claro e objetivo. Produ- 
za indicadores precisos para o público-alvo correto. 
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HAVERIA UM MODELO A SER SEGUIDO? 


Sim, um bom modelo. Se você procurar na internet páginas sobre 
“Acordos de Nível de Serviço” com certeza encontrará alguns modelos de 
documentos que podem ser úteis para você elaborar o seu próprio ANS. 
Não espere encontrar estes modelos nos livros oficiais da TTILº, pois, no- 
vamente, lá você encontrará referências a “o que” ele deve ter e não “como” 
ele deve ser. 

Tome também cuidado para não seguir modelos errados. Nem tudo o 
que você encontrará na internet está correto e nem tudo será aplicável à sua 
realidade. Nem todos os sites citados como exemplos estão necessariamente 
seguindo os conceitos da ITIL® da maneira adequada. 

Mas o que então poderia ser julgado como um bom modelo? A resposta 
é simples: aquele que segue os conceitos da ITIL®. Muitas pessoas buscam 
estes modelos prontos porque querem um atalho para chegar mais rápido ao 
resultado final. Isso acontece com modelos de catálogos, modelos de ANS, 
modelos de processos etc. Muita gente quer algo pronto porque não quer 
“perder tempo” tendo que entender todos os conceitos e requisitos para 
montar o seu próprio modelo. Se o seu estímulo para a busca de modelos é 
este, então talvez você deva reavaliar sua estratégia. 

Isso não quer dizer que quem já tenha estudado e compreendido todos 
os conceitos e requisitos para a criação do ANS (ou dos outros artefatos) 
não possa buscar modelos na internet para, dentro do melhor espírito de 
melhoria contínua, aprimorar o próprio modelo agregando ideias obti- 
das em outras fontes. Mas é preciso ter senso crítico e conhecimento para 
poder separar o bom do mau modelo. Sem ter o domínio completo dos 
conceitos envolvidos neste assunto, corremos o risco até de encontrar um 
bom modelo pronto, mas de implantá-lo e operá-lo de modo errado, com- 
prometendo o resultado final. O mesmo pode acontecer com os demais 
artefatos. Cuidado. 
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LIÇÕES APRENDIDAS: Ao procurar por modelos, concentre-se no conteúdo que 
eles apresentam e não só no formato de apresentação. Valide este conteúdo ve- 
rificando se está de acordo com os conceitos apresentados na ITIL®. Verifique a 
utilidade de tudo o que compõe seu ANS. 
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COMO CONSTRUIR E USAR 
UMA BASE DE CONHECIMENTO 
NA GSTI? 


Preparar a empresa para a GSTI 
Preparar a TI para a GSTI 
Construir um CMDB 
Construir um Catálogo de Serviços 


Construir Acordos de Nível de Serviço 


Construir uma Base de Conhecimento 


Implantar processos operacionais 


O tema base de conhecimento foi compreendido por muito tempo como 
um diferencial em projetos que buscavam melhorias de desempenho 
nas equipes de suporte, principalmente antes da ITILº V3 apresentar for- 
malmente este processo. 

Algumas empresas mais inovadoras vislumbravam também oportunida- 
des de redução de custos ou de melhoria da continuidade de seus serviços 
pela adoção de bases de conhecimento. Nos dias atuais não se discute mais 
se uma base de conhecimento será ou não necessária, pois a maior parte 
das empresas já reconhece seu importante papel na estrutura de suporte a 
serviços. 

Uma discussão ainda frequente é sobre o autoatendimento através de ba- 
ses de conhecimento usadas pelos próprios usuários dos serviços de TI. Real- 
mente, este é um tema polêmico que merece cuidado ao ser tratado. Muitos 
associam o autoatendimento somente à existência de uma base de conheci- 
mento na qual o usuário terá acesso a soluções para seus problemas e deverá 
implantá-las sozinho. Este não é um conceito completo! O autoatendimento 
é um conjunto de funções, assim como o serviço de autoatendimento de um 
caixa bancário que disponibiliza várias transações. 

Podemos pensar nele também como um conjunto de transações entre as 
quais: abertura de solicitações, consulta de status de uma solicitação, consulta 
a detalhes de configurações de serviços, consulta ao catálogo de serviços e 
ANS, esclarecimento de dúvidas, obtenção de informações sobre a progra- 
mação de atividades técnicas (janelas de processamento) e, finalmente, aces- 
so à base de conhecimento para encontrar soluções e implantá-las de modo 


autônomo. 
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Esta última transação tem sido questionada por muitos especialistas so- 
bre sua eficiência. Será que um usuário leigo com uma base de conheci- 
mento não levará mais tempo para resolver suas próprias demandas do que 
se ele fosse atendido por uma equipe qualificada? Muito provavelmente. 
Mas isso não significa que não haja espaço para o uso de bases de conheci- 
mento no lugar e na hora certos, dentro do processo de autoatendimento. 
Como diz um ditado popular: “Nem tudo será bom ou mal para todos em 
todos os momentos.” 

A história demonstra que estas discussões também não foram muito 
diferentes no passado. Em 1994, quase 10 anos antes de a ITILº V2 co- 
meçar a ser divulgada aqui no Brasil, já tínhamos, como consultores, uma 
visão deste cenário: vislumbrávamos um mercado de suporte técnico que 
acabaria dependendo muito fortemente de bases de conhecimento para 
sobreviver. 

Também nesta época ainda não se falava na abordagem do KCS (Know- 
ledge Centered Support), pois somente muitos anos depois esta visão co- 
meçaria a ser transmitida para o mercado brasileiro. Porém, em 1993, an- 
tecipando tendências e apostando em nossas estratégias para melhoria do 
processo de atendimento a clientes, iniciamos um projeto para a construção 
de um software de gestão de conhecimento (ainda voltado para o mercado 
de help desk, pois o termo service desk ainda não tinha chegado até nós) que 
implantava os conceitos de base de conhecimento e de processos de gestão de 
problemas. Hoje, boa parte das empresas já tem um KB (Knowledge Base) e 
algumas empresas até já adotam o KCS como modelo de operação. Outras, 
ainda céticas, mantêm-se à distância, observando para onde o mercado irá se 
direcionar, mas o caminho não tem volta. 

Independentemente do modo como as empresas têm abordado este tema, 
uma coisa é certa: todos reconhecem a importância deste novo artefato para 
a GSTI. Os modos de abordagem e até de implantação de bases de conheci- 
mento podem variar conforme veremos a seguir. Em função disso, diferentes 
resultados também poderão ser obtidos em diferentes áreas da organização. 
Os esforços e até ferramentas envolvidas poderão variar conforme a visão que 


se estabeleça para a gestão do conhecimento. 
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TODOS CONHECEM O QUE É UMA BASE DE CONHECIMENTO? 


Nestes anos todos de história da gestão de conhecimento, passamos por 
várias gerações (e interpretações) do termo “base de conhecimento”. Hoje, 
podemos dizer que todos eles convivem, pois a ITILº V3 se encarregou de 
criar algo tão genérico como um SGCS (Sistema de Gestão de Conheci- 
mento sobre o Serviço) no qual, então, tudo pode ser conhecimento, desde 
um simples incidente ocorrido com um serviço, passando pelas regras de 
negócio que o serviço atende, pelos perfis dos clientes e usuários deste servi- 
ço, pelo pacote de desenho do serviço, pela documentação deste serviço, sua 
configuração, seus processos, erros conhecidos, procedimentos operacionais 
e por aí afora. Tudo é conhecimento. 


Geração 1 Geração 2 Geração 3 


Sistemas Portais : |l 
corporativos 


especialistas 


A geração pela qual iniciamos neste assunto era aquela vinculada a siste- 
mas baseados em conhecimento, ou sistemas inteligentes, ou ainda sistemas 
especialistas: uma subárea da inteligência artificial. A ideia central associada 
ao conhecimento era de que seria possível capturar o conhecimento de um 
especialista (know-how) e armazená-lo numa base de conhecimento para 
que um sistema eletrônico que o acessasse pudesse simular o comportamento 
deste especialista na recomendação de ações, no diagnóstico, no esclareci- 
mento de dúvidas etc. Conceitos da década de 1980. 

Este foi o recurso que, em 1994, incorporamos como uma grande ino- 
vação em uma solução de service desk que projetamos, até mesmo antes de 


pensar em um CMDB (que também naquela época não tinha este nome). 
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Você deve estar pensando: “Isso deve ter sido muito útil” ou “este recurso 
deve ter sido um grande diferencial numa ferramenta naquela época.” Po- 
rém, paradoxalmente, não foi este o resultado obtido. O recurso era real- 
mente útil, mas pouco usado. À maior parte das empresas ainda estava preo- 
cupada demais em gerenciar filas de atendimento para poder dar atenção à 
gestão de conhecimento. Digamos que estávamos oferecendo o recurso certo 
na hora errada. 

A segunda geração pela qual passamos foi aquela vinculada ao conceito 
de bases de conhecimento como portais de conteúdo corporativo. Em 2001 
surgia o produto SharePoint da Microsoft, baseado no Microsoft Digital 
Dashboard, que já em 1999 havia dado o prêmio de “empresa do ano” à 
Microsoft no segmento de ferramentas de gestão de conhecimento, ou seja, 
nessa época portais de compartilhamento de informações corporativas eram 
denominados bases de conhecimento. 

Entendia-se que, se uma empresa buscasse por todos os seus documentos 
eletrônicos e depois os indexasse num mecanismo de busca, compartilhando- 
os através de um portal, teria então uma base de conhecimento corporativa. 
Esse recurso foi reconhecido e aplicado a várias áreas de negócio dentro das 
organizações, porém teve pouco destaque em processos de suporte dentro da 
própria TI, o que também é um paradoxo. 

Uma terceira geração vem agora se formando com os conceitos de ge- 
renciamento de conhecimento apresentados a partir da ITILº V3. Neste 
novo modelo de base de conhecimento, existe não só a geração 1, como 
também a geração 2 e ainda outros novos elementos agregados como co- 
nhecimento. 

Para a ITIL®, a gestão do conhecimento é uma evolução natural da ges- 
tão de dados e gestão da informação rumo à gestão da sabedoria. Precisamos 
agora, dentro destes novos preceitos, abrir nossas mentes para um novo es- 
copo da gestão do conhecimento. Em última instância, podemos definir que 
“tudo aquilo que esteja relacionado a um serviço em qualquer uma das fases 
de seu ciclo de vida pode compor nossa base de conhecimento sobre ele”, não 


só conteúdo, nem só know-how, mas ambos e muito mais. 
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Só que o que poderia ser um grande recurso à nossa disposição pode se 
transformar também em um risco se não planejado, implantado, administra- 
do e compartilhado de modo adequado. 

Definir o público-alvo, o escopo, os métodos de criação e manutenção, 
e até os mecanismos de publicação deste conhecimento devem ser preo- 
cupações essenciais para produzir mais este artefato da GSTI. Muitas vezes 
consideradas um complemento para a GSTI, as bases de conhecimento são 
hoje reconhecidas como alguns dos artefatos básicos para uma correta im- 
plantação de vários processos, entre eles a gestão de incidentes, a gestão de 


problemas e etc. 


PROCESSOS OPERACIONAIS 


CATÁLOGO 
DE 


SERVIÇOS 


LIÇÕES APRENDIDAS: O termo base de conhecimento pode significar diferentes 
coisas para diferentes pessoas. Procure identificar sobre o que as pessoas estão 
falando quando usam este termo. Crie conceitos e expectativas alinhadas entre 
todos os participantes do projeto. 
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QUEM SERÁ O BENEFICIADO COM A BASE 
DE CONHECIMENTO (BC)? 


Em muitos projetos, ao se falar em base de conhecimento, a primeira 
imagem que se estabelece entre a equipe da TI é a de um repositório onde 
“aquelas pessoas que não sabem algo poderão ter acesso para esclarecer suas 
dúvidas ou para obter recomendações de como agir”. Talvez esta visão tenha 
sido incutida nas pessoas pelas próprias ferramentas existentes no mercado, 
que por muito tempo associaram a ideia de base de conhecimento como si- 
nônimo de base de erros conhecidos ou base de procedimentos padrão. Este 
conceito era reforçado pela visão simplificada de base de conhecimento que 
existia ainda na ITIL® V2. Nesta visão, a base de conhecimento nascia e era 
usada associada ao Service Support, ou hoje algo mais ou menos equivalente 
às etapas de Service Transition e Service Operation. 

Hoje sabemos que a base de conhecimento começa a receber inputs des- 
de a fase de estratégia do serviço, ou seja, desde a concepção de um serviço, 
continuando a receber novos inputs durante todas as etapas de seu ciclo de 
vida, culminando com o uso intensivo na etapa de Service Operation. Se isso 
é verdade, então podemos assumir que muitas pessoas, de diversas manei- 
ras, poderão ser beneficiadas com a criação e manutenção de uma BC. 

Se observarmos ainda um pouco mais atentamente, os processos ITILO 
nos quais a BC estará sendo aplicada, ou simplesmente se nos concentrar- 
mos no objetivo final da ITIL®, veremos que as BC estarão beneficiando os 
clientes da TI e não somente a TI. Se pudermos aumentar a disponibilida- 
de dos serviços, oferecer maior qualidade e agilidade nas intervenções e se 
conseguirmos assegurar maior continuidade para os serviços aplicando BC, 
quem será o beneficiado? O cliente, com certeza. 

Colocar uma BC à disposição de seus clientes pode significar para você 
a oferta de um canal alternativo para melhorar o atendimento e o suporte. 
Já para seus clientes, se os conceitos não estiverem muito claros, esta mesma 
iniciativa pode significar a TI procurando meios para não ter mais que pres- 
tar suporte direto a seus clientes ou meios de se liberar de uma responsabili- 


dade. Cuidado! Falsos conceitos e percepções podem criar resistências e até 
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mau uso de excelentes recursos por parte dos clientes, sendo eles próprios os 
prejudicados. 

Lembre-se também do conceito de autoatendimento que discutimos no 
começo do capítulo e utilize este recurso na medida certa e no tempo cer- 
to. O exemplo do processo de autoatendimento provido pelas instituições 
bancárias serve como um grande referencial para nossas estratégias na TI. 
Lembre-se de que quando o processo de caixas automáticos foi liberado pe- 
los primeiros bancos no mercado, somente duas ou três transações muito 
simples (consulta de saldo, emissão de extrato e saque de dinheiro) estavam 
disponíveis. Isto fez com que os clientes não tivessem dificuldade em absor- 
ver a novidade. 

Imagine se já na primeira semana de lançamento dos caixas automáticos 
no mercado um banco tivesse criado um menu com 20 serviços divididos 
em três níveis de navegação em telas, oferecendo envelopes que deveriam 
ser preenchidos e colocados na máquina, coletando notas e moedas, gerando 
comprovantes de depósitos etc. Não teria dado certo. Fomos acostumados a 
usar recursos básicos para depois sermos submetidos a transações mais com- 
plexas. E hoje ninguém mais nega que é muito mais ágil fazer a própria 


transação do que entrar na fila para ser atendido. Pense nisso. 


LIÇÕES APRENDIDAS: Antes de construir uma BC, construa conceitos. Este arte- 
fato pode ser entendido como a base do autoatendimento e o autoatendimento 
como a base de um novo modelo de suporte, mas também podemos destacar 
para nossos clientes outros potenciais benefícios que eles teriam caso apoiassem 
nossas iniciativas de gestão de conhecimento. 


QUAL A DIFERENÇA ENTRE UMA BC E UMA BASE DE FAQ? 


Quando falamos em base de conhecimento muitas pessoas imaginam 


imediatamente algo parecido com uma coleção de perguntas e respostas do 
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tipo “como fazer”, “o que fazer” etc. Esta imagem não está de todo equivo- 
cada. Ela é baseada num dos modelos de base de conhecimento que, com o 
passar do tempo, acabaram sendo proliferados pela internet em diversos sites 
de suporte a produtos. Porém, este não é o único e nem o mais abrangente 
dos modelos. De que outro modelo estamos então falando? 

O novo conceito ITILº de SGCS propõe que conhecer, por exemplo, 
quais são os serviços que estamos oferecendo (o catálogo de serviços), como 
eles estão construídos (CMDB), quais são os níveis de serviço estabelecidos 
(ANS), quem são os usuários dos serviços, quais foram os incidentes que já 
aconteceram para aquele serviço, quanto investimos e quanto já gastamos 
com a operação deste serviço, entre tantas outras coisas, são todos compo- 
nentes formadores da grande base de conhecimento sobre os serviços. Não 
por acaso deixamos este assunto para ser tratado por último. O motivo é que 
na nova visão da gestão de conhecimento apresentada pela ITILº podemos 
incluir todos os demais artefatos já vistos até agora nos demais capítulos 
como inputs para o processo. 

Isso nos faz pensar que agora, quando falamos em base de conhecimen- 
to, não estamos mais nos referindo somente ao conjunto de perguntas e 
respostas capazes de responder a perguntas do tipo: “Como fazer” (how). 
Agora, a nova base de conhecimento deve responder aos tópicos dos 5W 
e 2H. Podemos, por exemplo, identificar na nova concepção da base de 


conhecimento: 


e WHO (quem usa um serviço, quem fornece um serviço, quem suporta 
um serviço, quem já teve incidentes com este serviço, quem solicitou o 
serviço, quem definiu o SLA do serviço, quem é o fornecedor associado 
ao serviço etc.). 


e WHAT (o que compõe um serviço, o que foi feito para criá-lo, o que 
deve ser provido, o que o serviço gera de saídas, o que deve ser feito 
para operá-lo, o que o usuário espera de retorno pelo uso do serviço 
etc.). 
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WHEN (quando o serviço foi criado, quando ele deve estar disponível, 
quando ele esteve indisponível, quando ele poderá ser interrompido, quan- 
do ele é usado, quando ele será revisado, quando poderá ser alterado, 
quando foi alterado etc.). 


WHERE (onde o serviço está disponível, onde o serviço foi implantado, 
onde podemos obter recursos, onde queremos chegar, onde estão os 
pontos de monitoração, onde precisamos melhorar, onde ele é usado 
eic.). 


WHY (por que o serviço parou, por que o usuário requer um nível de 
serviço, por que não conseguimos atender ao nível de serviço, por que a 
capacidade está comprometida, por que ele é essencial ao negócio etc.). 


HOW (como se opera o serviço, como se atendem aos incidentes, como 
o serviço foi implementado, como podemos negociar níveis de serviço, 
como uma saída é produzida etc.). 


HOW MUCH (quanto custa o serviço, quanto tempo ele esteve indisponí- 
vel, quanto devemos oferecer, quanto podemos oferecer, quanto foi utili- 
zado daquilo que foi oferecido etc.). 


Algumas pessoas, vendo todas estas perguntas, poderiam imaginar que 


um conjunto de FAQ (Frequently Asked Questions) poderia ser utilizado 


para estruturar uma base de conhecimento. E verdade. Para algumas delas, 


sim, mas observe atentamente, pois muitas destas perguntas não são respon- 
didas através de FAQ. 


Algumas das respostas às perguntas anteriores serão retiradas do PDS 


(Pacote de Desenho do Serviço), outras, do catálogo de serviços, da base de 
capacidade, da base de disponibilidade, da base de fornecedores, dos ANS, 
do CMDB, da base de incidentes, dos indicadores etc. 


As FAQ tradicionais se assemelham muito mais a estruturas de arma- 


zenamento de erros conhecidos e de procedimentos padrões, não sendo, 
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portanto, excluídas do escopo do SGCS, mas nem sempre sendo a estrutura 
ideal para todos os casos e para todas as perguntas dos 5W e 2H. As FAQ, 
por possuírem uma estrutura formal composta por perguntas e respostas pre- 
definidas, podem, por outro lado, ser produzidas a partir do uso dos reposi- 
tórios e artefatos que compõem o SGCS. 

Imagine, por exemplo, que tenhamos identificado um grande número de 
pedidos de informação no service desk sobre o horário de disponibilidade 
de um determinado serviço. Temos esta informação no catálogo de serviços, 
mas podemos transpor a informação num formato de FAQ em uma área de 
publicação para autoatendimento. Isso pode facilitar a localização da infor- 
mação pelos usuários que não possuem intimidade para manusear o catálogo 
de serviço. 

Chegamos, então, à conclusão de que as FAQ podem compor a BC se ti- 
verem sido criadas com informações que não estejam reproduzidas em outras 
partes desta mesma BC e que também possam ser mídias de apresentação do 
próprio conteúdo já disponível na BC, facilitando o acesso a uma mídia de 
fácil compreensão pelo cliente. 


LIÇÕES APRENDIDAS: Uma estrutura de FAQ pode compor uma BC, mas uma 
estrutura de FAQ não é a própria BC, pelo menos no conceito ITILº. 


COMO CRIAR UMA BC? 


Pelo escopo da base de conhecimento que já apresentamos, você pode 
já ter percebido que a criação de uma BC não é um evento finito, mas um 
processo contínuo. Como a BC pode ser composta por um conjunto bastante 
grande de elementos e vários deles pertencem a diferentes fases do ciclo de 
vida do serviço, então teremos vários inputs em vários momentos alimentan- 
do esta BC. 

Se a abordagem de melhoria contínua (PDCA) for aplicada também ao 


processo de gestão de conhecimento, teremos então também vários momentos 
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em que novas porções da BC serão criadas em tempos futuros. A pergunta 
que pode surgir é: por onde devemos começar? 

A resposta a esta pergunta depende de outra pergunta: será que o mais 
importante é escolher por onde “devemos” começar ou por onde “podemos 
começar”? Isso significa que nem sempre iniciaremos a criação de nossa base 
de conhecimento pelo ponto ideal. E qual seria este ponto ideal? 

O conhecimento sobre um serviço, como já vimos, se inicia já na fase da 
estratégia do serviço. Ao definirmos as estratégias de um serviço, já estamos 
começando a coletar conhecimento sobre ele. Logo, este seria o ponto ideal 
por onde deveríamos começar com nossa BC. Mas, voltando à questão de 
começar por onde “podemos”, temos que lembrar que, quando definirmos 
que iremos iniciar a criação de uma BC já teremos, neste momento, inú- 
meros serviços em operação. Não poderemos voltar à fase de estratégia do 
serviço, nem tampouco à fase de desenho ou de transição. Estaremos assu- 
mindo um serviço na fase de operação e então o ponto por onde “poderemos” 
começar será com a captura de conhecimento obtido durante a operação 
deste serviço. 

É claro que, para os novos serviços que venham a ser criados, poderemos 
adotar a estratégia de começar por onde “devemos”, ou seja, pelo começo. 
Mas, em ambientes de TI já maduros, que são aqueles que normalmente 
buscarão a adoção das melhores práticas da ITILº, será muito menos fre- 
quente a criação de novos serviços do que a operação de serviços já existentes. 
Teremos, então, muito mais facilidade de obter conhecimento sobre serviços 
operacionais do que de obter conhecimentos sobre novos serviços. 

Outro ponto que poderá nos definir uma estratégia para início de criação 
de nossa BC é a finalidade para a qual ela será criada. Já dissemos que de- 
vemos sempre pensar em qual será a finalidade, quais serão os benefícios e 
quais serão os resultados de nossas iniciativas. Para conseguir apoio para nos- 
sas iniciativas devemos apresentar os resultados que elas produzirão. Logo, 
conforme o resultado que você busque, poderá escolher um ou outro ponto 
de início para sua BC. 

Um dos principais resultados buscados pelas equipes de TI quando criam 


uma BC é, por exemplo, melhorar os índices de resolução de chamados no 
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nível 1. Outras empresas também podem citar que buscam melhorar a qua- 
lidade dos procedimentos executados por suas equipes de TI, e assim por 
diante. Considerando somente estes dois motivos apresentados, por onde 
então “deveríamos” começar? 

Deveríamos começar pela criação de conhecimentos que sejam utilizados 
no tratamento de chamados no nível 1, ou seja, uma base de erros conhe- 
cidos, uma base de modelos de incidentes, uma base de procedimentos pa- 
drões para atendimento de requisições, uma base de dúvidas frequentes etc. 
Se estes são os recursos que vão produzir os resultados que buscamos, e se 
com isto os clientes serão beneficiados, então por que não começar por aí? 
Isso não significa que não tenhamos também que buscar o desenvolvimento 
de outras áreas da BC. Isso com certeza fará parte do seu plano de melhoria 
contínua do processo de gestão de conhecimento, certo? 

Mais uma vez, precisamos prestar atenção num ponto importante: não se 
trata somente de definir “por onde começar”, mas de entender “por que co- 
meçar” e “para que começar”. Se seu plano de criação da BC estiver orientado 
para resultados e principalmente se estes resultados estiverem centrados nos 
clientes as chances de seu plano dar certo serão muito grandes. Mantenha 


isso em mente. 


LIÇÕES APRENDIDAS: Concentre-se em dois pontos principais: “Por que criar” e 
“para quem criar” a BC. Só depois defina “como criar” a BC. Este mesmo princi- 
pio se aplica ao CMDB, ao catálogo e aos ANS. 


COMO MANTER UMA BC? 


Assim como nos casos de outros artefatos que já citamos, uma BC só será 
efetivamente uma ferramenta útil se for atualizada constantemente. Por este 
motivo a gestão de conhecimento mereceu maior destaque na ITIL®V3, 


inclusive sendo criado um processo específico para tratar deste tema. 
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Usando uma analogia bem simples, já vi pessoas que dizem que “se você 
não pode cuidar de um bicho de estimação, então é melhor nem comprar 
um”. E isso realmente é verdade. No caso das BC, a mesma afirmação é váli- 
da: “Se você não terá condições de manter sua BC atualizada, então é melhor 
nem criá-la”. Possuir uma BC na qual não se possa assegurar a integridade 
das informações, que não esteja completa, que possua informações obsoletas, 
que tenha processos e scripts de atendimento desatualizados etc. pode signi- 
ficar um grande risco. 

Uma das finalidades da BC é a de apoiar o processo de atendimento para 
permitir intervenções mais ágeis. Agora imagine se aumentarmos a agilidade 
e passarmos a fazer coisas erradas mais rapidamente. De que adiantaria ter 
uma BC? Seria melhor deixar a equipe sem este recurso, tendo pouca agili- 
dade, mas pelo menos não correndo o risco de seguir orientações erradas. 

Sim, mas como poderemos assegurar sua atualização? À primeira coisa 
a fazer é ter um processo integrado às atividades de vários outros processos. 
Esta é uma visão que procuramos sempre transmitir quando falamos em 
processos ITILº. Eles podem ser estudados, mapeados, definidos, medi- 
dos, controlados e gerenciados numa visão monolítica, ou seja, focando-se 
somente naquele processo. Mas, na hora de serem executados, é importante 
que se perceba que cada atividade de um processo pode ser encadeada com 
outras de processos diferentes num único processo operacional que esteja 
sendo realizado. 
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Imagine que um técnico é acionado para atualizar um sistema no equi- 
pamento de um usuário e, ao tentar executar o procedimento descrito, en- 
contra inconsistências que o obrigarão a proceder de outro modo. Neste 
pequeno exemplo, temos uma atividade operacional (a instalação de um 
novo sistema) que pode ter em sua execução uma mescla de atividades da 
gestão de requisições, gestão de configuração, gestão de liberação, gestão 
de conhecimento etc. 

Ao tentar executar o procedimento descrito na base de conhecimento 
e perceber que ele está inconsistente, este técnico deveria estar orientado 
a realimentar o processo de gestão de conhecimento com o apontamento 
desta não conformidade existente na BC. Se ele não fizer isto, neste exa- 
to momento, mesmo contornando a dificuldade existente, ele deixará que 
outro técnico venha amanhã a ter a mesma dificuldade, pois a BC não será 
corrigida. 

Perceba que a manutenção da BC, que é uma atividade da gestão do co- 
nhecimento, está sendo integrada ao processo operacional do técnico, mes- 
mo não sendo necessariamente ele quem fará a correção do item encontrado 
em não conformidade. Em ambientes de menor porte, talvez até o próprio 
técnico receberia, então, a responsabilidade de apontar a correção necessá- 
ria no procedimento, de proceder sua validação e assim efetivar a correção. 
Independentemente das atribuições de uma matriz RACI criada para este 
fim, o importante é que seja possível assegurar a manutenção e evolução de 
nossa BC. 

Também outros processos, como a gestão de configuração, poderão apon- 
tar necessidades de adequação da BC pela remoção ou adição de novos IC e 
novas tecnologias. Seguindo este mesmo raciocínio, veremos que os estímu- 
los para manutenção e atualização de nossa BC virão na verdade de todos os 
demais processos em todas as demais fases do ciclo de vida de um serviço. 
O processo de gestão de conhecimento, mais do que gerar outputs que serão 
úteis para inúmeros outros processos, também receberá deles inputs para 
sua manutenção. Portanto, não pense em um esforço isolado para assegurar 
uma BC atualizada, mas sim num esforço distribuído por todos os demais 


processos. 
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LIÇÕES APRENDIDAS: Mais importante do que o processo de criação da BC é o 
processo de manutenção da BC. Garantir a integridade e a atualidade de uma 
base de conhecimento é ponto essencial para criar motivação para o uso da BC. 
Integre os processos operacionais de modo que cada um possa realimentar os 
demais com os inputs que detecta ou produz. 


COMO DIVULGAR UMA BC? 


A resposta a esta pergunta envolve questões relacionadas não somente a 
“como fazer a divulgação”, mas também “para quem divulgar”, “quando di- 


vulgar” e “o que divulgar”. Vamos ver cada um destes pontos a seguir. 


QUANDO PARA QUEM DE QUE MODO 


Quando divulgar? 


Um primeiro ponto que a prática tem demonstrado é que existe um mo- 
mento certo para divulgar a existência de uma BC. Se a divulgação ocorrer 
muito cedo, correremos o risco de frustrar as expectativas dos usuários da 
BC, pois eles irão encontrar pouco conteúdo aplicável a suas necessidades. 
Se as experiências iniciais de busca na BC não tiverem sucesso, poderemos 
associar a imagem de falta de efetividade no uso a um recurso que deveria 
justamente criar a imagem contrária. Já se divulgarmos muito tardiamente 
nossa BC, criaremos também uma imagem de falta de efetividade no proces- 
so, pois os usuários verão muito esforço sendo despendido para sua criação 
sem que resultados estejam sendo realmente produzidos. 
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Uma estratégia que pode ser aplicada neste caso é segmentar a BC em 
diferentes unidades de conhecimento, seja por tema, por serviço, por tec- 
nologia, por área, por processo etc. Depois de segmentada, definimos então 
uma fração que seja prioritária para atendimento, seja pela quantidade de 
pessoas beneficiadas, pela carência de informações, pela importância do pro- 
cesso envolvido etc. 

Para este segmento escolhido, desenvolvemos um conteúdo também fo- 
cado nos resultados esperados para ele. Se detectarmos que a carência é por 
procedimentos, ou por informações sobre os serviços, ou por referências de 
usos dos serviços etc., então este será o ponto de início de alimentação da 
BC para este segmento. Procure então utilizar a abordagem dos “80-20” para 
criação do conteúdo, ou seja, cubra 80% da sua necessidade, deixando os 20% 
do conteúdo faltante, que tomariam os outros 80% do esforço, para serem 


realizados numa próxima etapa do ciclo de PDCA da BC. 


LIÇÕES APRENDIDAS: Divulgar uma BC muito cedo e não ter conteúdo a oferecer 
pode gerar resultados tão ruins quanto levar muito tempo para criar conteúdo em 
excesso e demorar muito a mostrar resultados. 


Para quem divulgar? 


O público-alvo de uma BC dentro da visão que a ITIL estabelece no 
processo de gestão de conhecimento é bastante abrangente, como já vimos. 
Se todo o conhecimento sobre todo o ciclo de vida de um serviço pode ser 
disponibilizado na BC então seu público-alvo também abrange indivíduos 
em todas estas fases. Porém, tal panorama só será verdadeiro em longo pra- 
Zo, pois temos que imaginar que já teremos um grande legado produzido 
e sendo operado quando iniciarmos com a adoção das melhores práticas 


da ITILS. 
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Todo este legado não terá produzido conhecimentos nas fases estratégica, 
de desenho e de transição. Será a fase de operação que irá concentrar boa 
parte das iniciativas de produção de conhecimento. Numa primeira etapa 
talvez tenhamos definido um escopo para início de nossa criação de BC e 
então teremos um público-alvo também reduzido. 

Isso significa então que só devemos divulgar a BC para quem será benefi- 
ciado inicialmente por ela? Não, com certeza não. Mesmo que algumas áreas 
internas ou externas a TI não tenham inicialmente alguma vinculação com 
nossas iniciativas de geração da BC, é recomendável que elas também parti- 
cipem do processo de divulgação que faremos, tanto nos níveis operacionais 
como nos níveis gerenciais. Isso pode facilitar o futuro comprometimento 
destas áreas quando forem definitivamente envolvidas e reduzir a resistência 
pelo desconhecimento das iniciativas. 

Também a divulgação a estas áreas não diretamente envolvidas em nos- 
sas primeiras iniciativas pode fazer com que detectemos novas potenciais 
áreas para aplicação da BC. Já discutimos a questão relativa à quando di- 
vulgar nossa BC, afirmando que a divulgação não pode ser muito prema- 
tura. Mas será que uma divulgação prematura não traria como vantagem 
a possibilidade de definir um escopo mais alinhado com as expectativas e 
necessidades da organização? A resposta é sim, e logo você vai compreen- 
der por que as duas linhas de raciocínio parecem divergentes, mas são, na 


verdade, complementares. 


LIÇÕES APRENDIDAS: Criar expectativas pode ser uma estratégia para obter apoio 
e reduzir a resistência, porém criar expectativas que não possam ser atendidas fu- 


turamente pode aumentar ainda mais a resistência e a falta de apoio. 
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O que divulgar? 


A resposta a esta pergunta é o que vai nos levar a compreensão dos mo- 
tivos que podem nos fazer adiar a divulgação, por um lado, mas antecipá-la 
por outro. À questão que esclarece tudo isso é que a divulgação dos planos, 
dos objetivos, dos benefícios esperados, das estratégias e dos requisitos de 
implantação da BC devem ser antecipados e amplamente divulgados. Já o 
conteúdo produzido na BC deve ser adiado, ou, pelo menos, não prematu- 
ramente divulgado ou divulgado restritivamente àqueles que estejam direta- 
mente ligados às iniciativas executadas. 

Todos podem ser motivados a participar no presente momento, ou até 
no futuro, se conhecerem os benefícios que poderão obter com nossos pla- 
nos. Porém, lembre-se de que o que interessa são resultados e não somente 
planos. 

Tenha em mente que você não é obrigado a prometer maiores ou meno- 
res resultados, mas que tudo aquilo que você prometer terá de cumprir sob 
pena de criar um foco de resistência às suas próximas iniciativas. Portanto, 
não exagere nos resultados que você irá divulgar para seus planos. Seja 
realista. 

Nosso objetivo neste livro não é fazer uma revisão de conceitos ou apre- 
sentar objetivos, benefícios, estratégias, requisitos, nem sequer planos de im- 
plantação do processo de gestão de conhecimento. Vamos deixar este con- 
teúdo para ser consultado e estudado em mais detalhes no livro de Service 
Transition da ITIL®, pois, nos cursos de ITIL Foundationsº, o foco no 
processo de gestão de conhecimento visa somente conceitos básicos. Para 
que você tenha sucesso na implantação deste processo, será essencial, além 
de seguir as orientações apresentadas aqui, conhecer com maior profundida- 
de o processo de gestão de conhecimento. 


LIÇÕES APRENDIDAS: Apresente planos, objetivos, vantagens, estratégias e requi- 
sitos para todos. Apresente conteúdos para os que possam valorizá-los. 
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De que modo divulgar? 


A divulgação dos conceitos, objetivos, benefícios, estratégias, requisitos 
e planos de implantação, que será realizada já na fase inicial da implanta- 
ção do processo de gestão de conhecimento, não deve ter formalismo em 
excesso. Muitos projetos acabam por criar a ideia de que a BC será uma 
panaceia, ou uma solução para todos os problemas existentes. Outros criam 
a figura de que a BC é algo complexo, muito abrangente, que requer muito 
esforço para ser executada e mantida. Mesmo que algumas destas caracte- 
rísticas possam até ser verdadeiras, é importante minimizar o foco nestes 
pontos e procurar destacar os benefícios que a BC irá produzir. Resultados, 
como sempre! 

Se voltarmos aos primeiros capítulos deste livro, encontraremos um dos 
objetivos centrais da ITILO: “Produzir resultados que satisfaçam nossos 
clientes.” Assim, como nos demais processos, toda a divulgação do que será 
feito, para quem será feito, como será feito etc. deve ser centrada em “o que 
isto irá produzir de resultado e como trará melhor nível de satisfação ao 
cliente.” 

Procure os pontos que hoje possam estar sendo assinalados pelos pró- 
prios clientes como deficiências da TI e, usando os recursos que a BC provê, 
demonstre que com esta iniciativa eles poderão ser minimizados. Com esta 
abordagem poderemos conquistar o engajamento dos clientes mais facilmen- 
te, pois eles vislumbrarão vantagens diretas para suas áreas, caso o processo 
de gestão de conhecimento venha a ser implantado. 

Já a divulgação do conteúdo criado na BC, realizada após o processo de 
gestão de conhecimento estar operando e produzindo seus resultados, deve 
ser realizada gradativamente para as áreas envolvidas, procurando sempre 
iniciar com as áreas que tenham demonstrado durante a fase inicial maior 
identificação e engajamento como processo. 

Escolha uma primeira área (interna ou externa) que possa ser motivada 
a utilizar o conteúdo produzido e que demonstre publicamente os benefi- 


cios que tenha obtido. Isto poderá servir de motivação para as demais áreas. 
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Assim, gradativamente, produziremos um efeito de convencimento para as 
áreas ainda não agregadas ao processo, reduzindo as resistências à adoção do 
recurso criado. 

Outro aspecto importante que deve ser ressaltado quanto à divulgação 
do conteúdo da BC é que este conteúdo não visa somente transmitir co- 
nhecimentos a quem “não sabe algo”. Por muito tempo o conceito de BC, 
principalmente aquela baseada numa estrutura de FAQ, foi associado a um 
repositório de perguntas e respostas que seriam consultadas para “dirimir 
dúvidas” ou para “ensinar” pessoas que precisavam “aprender” algo. Já vimos 
no decorrer deste capítulo que este conceito foi expandido e que hoje uma 
BC não é mais apenas uma coleção de FAQ. Se imaginarmos que nossa 
BC contém, por exemplo, um conjunto de procedimentos e instruções de 
trabalho, então ela deixa de ser um artefato para consulta daqueles que “não 
sabem algo” para se transformar em um recurso para aqueles que “querem 
fazer bem feito”. 

Esta nova visão do conteúdo da BC precisa ser divulgada em todos os 
níveis da organização, principalmente no gerencial. É essencial que todos 
reconheçam que a BC é um instrumento de melhoria da qualidade e não só 
um instrumento de preservação e transmissão de conhecimento. 

Se um gerente, por exemplo, perceber que um determinado técnico de sua 
equipe acessa constantemente a BC durante suas atividades diárias, como 
ele deveria entender isso? Deveria pensar que este técnico tem dificuldades 
em aprender e por isso está constantemente consultando instruções sobre 
como fazer algo? Ou deveria pensar que este técnico está preocupado em 
seguir fielmente os procedimentos lá contidos para garantir a qualidade das 
atividades que executa? À visão que este gerente venha a ter da finalidade 
e do conteúdo desta BC poderá ser decisiva na interpretação do que está 
acontecendo com o técnico, motivando a própria equipe a alimentar, manter 


e consumir o conteúdo da BC. 
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LIÇÕES APRENDIDAS: Apresente os conceitos, mas concentre-se nos resultados. 
Crie uma nova visão da finalidade e do conteúdo da BC entre os técnicos e prin- 
cipalmente no nível gerencial. Muitas resistências poderão ser minimizadas com 
essa ação. 
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PROCESSOS? 


Preparar a empresa para a GSTI 
Preparar a TI para a GSTI 
Construir um CMDB 
Construir um Catálogo de Serviços 


Construir Acordos de Nível de Serviço 


Construir uma Base de Conhecimento 


Implantar processos operacionais 


C onsiderando que tenhamos desenvolvido nosso projeto de implantação 
da GSTI, passando pelas fases de preparação da organização, prepa- 
ração da TI e produção dos artefatos de apoio que citamos até aqui, chega 
então o momento decisivo de partir para a implantação dos processos opera- 
cionais de nosso service desk. Sim, porque a esta altura outros processos de 
apoio já devem ter sido implantados para manter os artefatos criados. 

Revendo a literatura de ITIL Foundations®, você vai rapidamente iden- 
tificar os processos que vão lhe dar apoio na manutenção do CMDB, do 
catálogo de serviços, dos contratos de SLA e da base de conhecimentos. 
Verifique, estude-os e implante-os. 

Resta agora definir uma estratégia para começar a operação de nosso ser- 
vice desk. Muitas empresas, neste momento, definem que irão se concen- 
trar na gestão de incidentes implantando-a primeiro de modo completo para 
depois abordar outros processos tais como gestão de requisições, gestão de 


mudanças, gestão de problemas etc. Mas será esta uma boa alternativa? 


QUAL A MELHOR ABORDAGEM? 


Muitas pessoas têm se questionado sobre este ponto: seria melhor im- 
plantar um processo de cada vez de modo completo, para só então prosseguir 
para os demais, ou abordar vários processos simultaneamente de modo mais 
superficial e depois aperfeiçoá-los gradativamente? A resposta que podemos 
apresentar para esta pergunta se baseia numa constatação teórica e prática. 

Do ponto de vista teórico, podemos encontrar várias referências na pró- 
pria ITIL® de que os processos são integrados, de que existem entradas e saí- 


das interconectando os processos, de que em uma dada função (por exemplo, 
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o service desk) teremos vários processos sendo operados e, principalmente, 
de que os processos devem evoluir continuamente através das iniciativas de 
melhoria contínua. 

Isso tudo parece apontar na direção teórica de que não devemos buscar 
muita profundidade nos processos abordados num instante inicial. Devemos 
deixar os aperfeiçoamentos e aprofundamento nas melhores práticas de cada 
processo para serem feitos ao longo de um período evolutivo. Assim, a res- 
posta teórica seria de que é melhor optar por ter vários processos simples em 


vez de somente um completo. 


PROCESSO 1 Processo 1 Fase 1 | Processo 2 Fase 1 | Processo 3 Fase 1 


Co RR 
CO O 


Implantação Implantação 
em profundidade em abrangência 


Do ponto de vista prático, outras questões podem apontar na mesma di- 
reção de que vários processos — e não somente um — devem ser abordados 
inicialmente. O primeiro ponto a ser verificado é: imagine que seu service 
desk irá começar a operar amanhã. Você só tem o processo de gestão de in- 
cidentes tratado até agora, porém de modo bastante completo. O que acon- 
tecerá às 8h30, logo após o service desk iniciar suas operações, quando um 
usuário ligar solicitando uma cópia de um manual que ele deseja obter para 
poder conhecer um sistema que está pensando em usar? Iremos tratar esta 
demanda pelo processo de gestão de incidentes? Não iremos tratar? Iremos 
tratar sem qualquer processo? 

Algumas pessoas responderão que irão registrar esta solicitação como 


um incidente, mas a tratarão de modo diferente de um incidente. Pessoal- 
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mente, já vi isso acontecer em mais de uma empresa. Todos podemos ima- 
ginar que isso poderá prejudicar futuros indicadores, certo? Poderíamos 
também citar outras situações que não podem ser tratadas como incidentes 
sendo atendidas pelo service desk. A pergunta que fica é: podemos ter um 
service desk operando só com um processo de gestão de incidentes? Na 


rática, parece que não. 
, 


O QUE É ESSENCIAL EM CADA PROCESSO? 


Todos os processos citados pela ITILº, em todas as fases do ciclo de vida 
do serviço, têm um conjunto de conceitos: melhores práticas, papéis, entra- 
das e saídas, atividades, políticas, métricas etc. Isso é abordado quando se 
mostra o conceito de processos dentro da ITILº. Logo, a definição do grau 
de aprofundamento que deveremos dar em cada processo se resumirá a esco- 
lher quais destes elementos deverão constar em cada fase de nosso plano de 
implantação de cada um deles. Todos aqueles itens que não sejam cobertos 
por uma dada fase de nossa implantação serão candidatos ao nosso plano de 
melhoria contínua do processo. 

Assim se, por exemplo, em uma primeira abordagem do processo de ges- 
tão de incidentes, optarmos em não abordar o conceito de “incidentes maio- 
res” (major incidents) formalmente, criando para eles um processo formal de 
tratamento, poderemos, numa próxima fase, incluir esta abordagem. Isso 
não quer dizer que não venham a ocorrer “incidentes maiores” enquanto 
estejamos operando nosso service desk na fase 1. Porém, se eles ocorrerem, 
serão tratados com incidentes de alta severidade sem as melhores práticas 
recomendadas para incidentes maiores. 

Deixaremos o estudo das estratégias de implantação dos demais processos 
ITILº para um próximo livro. Acreditamos que, com todo o material aqui 
apresentado, você já terá boas condições de preparar um ótimo ambiente 
para sua implantação da GSTI. 

Bom trabalho! 


241 


CONCLUSÃO 


N o prefácio deste livro dissemos que nosso objetivo não era apresentar 
um roteiro infalível para o sucesso na implantação da gestão de serviços 
de TI. A principal motivação era apresentar lições aprendidas através do uso 
de uma abordagem que acreditamos ser bastante efetiva para ser usada na 
adoção da ITIL® como referência para a GSTI. 

Para concluir, escolhemos apresentar alguns pontos que achamos essen- 
ciais para se manter em mente e que estão comentados ao longo do livro. 
Recomendamos que você reveja cada um deles se necessário. Eles não estão 
citados necessariamente em ordem de importância, pois cada projeto pode 
exigir maior ou menor cuidado com cada um. 

O sucesso da adoção da ITILº como base para um processo de gestão de 


serviços de TI depende de: 


Entender que a implantação da Gestão de Serviços de TI exige mudan- 
ças na organização e preparar a organização para absorver estas mu- 
danças. 


Entender que a implantação da Gestão de Serviços de TI exige mudan- 
ças na Tl e obter apoio incondicional de todos para estas mudanças. 


Criar um conjunto de artefatos básicos que darão suporte aos proces- 
sos operacionais e gerenciais da GSTI. 


Implantar um conjunto de processos mínimos para assegurar a preser- 
vação destes artefatos para depois abordar os demais processos de 
relacionamento com clientes. 
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Adotar uma abordagem que permita um maior conjunto de processos 
com menor aprofundamento particular, em vez de buscar o aprofunda- 
mento em um único processo, relevando os demais. 


E finalmente, arriscando apresentar uma recomendação que penso ser 


aplicável a todas as nossas iniciativas de sucesso na GSTI: 


Direcionar, sempre, todas as iniciativas para um único foco: 
resultados para o cliente. 


O mais importante não é como as coisas serão feitas, 
mas por que e para quem serão feitas! 


Obrigado e bom trabalho. 
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